Jamie Totten at Klue
Hi, and welcome to the Design Systems podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think. Go ahead and tweet us @theDSpod. We'd love to hear from you.
Chris Strahl: Hey everybody. Welcome to the Design Systems podcast. I'm your host, Chris Strahl. Today I'm here with Jamie Totten. Jamie, why don't you introduce yourself and Klue?
Jamie Totten: Sure, yeah, thanks for having me. Jamie Totten, I'm a UX engineer at Klue. We are an AI powered competitive enablement platform used by product marketing, competitive intelligence and sales enablement teams.
Chris Strahl: So in the world of a tech company that's AI enabled and obviously in your startup journey, you're still relatively early in that. What does a design system look like for an organization like Klue?
Jamie Totten: We've been around for a little bit, but the market is still kind of emerging around competitive intelligence and competitive enablement. For us, a design system is really focused on the kind of guild format. There's a great Atlassian article that references how Spotify has their team set up, and that's how we work where people are more or less volunteers. There's no fixed leader. There's somebody who's kind of the guild coordinator, which would be me, and then it's all kind of volunteer
Chris Strahl: Within that framework of resourcing. What does the design system actually power? Is that a part of your core product? Is it a part of the marketing website? Is it all of the above is what runs on the design system.
Jamie Totten: My dream is that eventually it powers everything. Right now it powers the front end of our web app, so we have a kind of standalone installable package, which is our design system, which is installed into our front end and that controls all of our components that are built so far.
Chris Strahl: The reason why this conversation is so exciting for me is that very often on this podcast we have really big companies that have multimillion dollar budgets and dozens of people working on these systems to build product. In your case, it's a lot more constrained. It's not to say that you have no resources at all, you do, but it's definitely not a bunch of dedicated people or a huge amount of dedicated budget to solving this problem. Yet your organization and you yourself have felt like there's a lot of value here. Tell me about what's really led you to focusing on systems inside of what still represents a pretty small company.
Jamie Totten: Yeah. I think for us, investing in a design system is really, we want all of those great benefits that comes with a design system. We want that increased velocity and speed, and we want our consistency and we have a great design director who's fully on board with the idea of the more we can componentize and make those micro design decisions, the faster we can move as both a design team and a front end team and a product team.
Chris Strahl: So being the CEO of a startup myself and understanding what some of these constraints that you're probably working within are, how do you actually go about feasibly doing this? I mean, we're a design system company, and so we sort of have to have one. If we didn't have a design system, that would be probably weird. When it comes to another organization that is really constrained, where I'm sure that your job varies fairly dramatically from month to month, and I'm sure that there's lots of other people in the company that also have this sort of chaos that is intended to be controlled but is also very present at every company of your size. How do you actually get something done?
Jamie Totten: Yeah, how do we get something done? I guess our order of working is because we're a guild and because it's volunteer, we meet on a every other week basis, and I have blocked a three hour window into people's calendars where we have on the west coast here, we have from 9:00 AM until noon where we meet and we spend the first hour going over our backlog, doing some refinement, discussing design system issues and previous action items, et cetera. We use GitHub for our issue management and then we will delegate some tasks out to people, anybody who needs one, and then we'll break after the first hour or less and then get into a two hour kind of dedicated working session. And the purpose of the working session is really when everybody's a volunteer and everybody belongs to a feature team, we need to make sure that we actually have some carved out time for people to do this work uninterrupted by their managers or their feature team needs to work on moving some of the design system components forward it and it's doubly beneficial when the component maybe that's being needed at the time coincides with a product feature.
Chris Strahl: Gotcha. So you don't have dedicated resources, but you do set aside dedicated time to focus on what are the common patterns? What are the common things we can put inside of a product system that ultimately represent value across the whole team in an organization that caress about the design system that values it? Like you said, you have a design director that's very involved in this process. How do you go about going around to all the other people and managers and collecting that time? I can imagine that that's sometimes a daunting effort when you have this initiative, this idea, this direction, but no real dedicated resources to that cause. Is that just something where you went and met with everybody's manager individually that people volunteered? How did that three hour block come to exist?
Jamie Totten: We've tried many iterations of how we would do this work, and this is where we are now. Previously, we did something similar in a shorter period of time where we'd ask the people who were volunteering to come to the meeting, self-select an issue, take it back to their feature team, try to get it into that team sprint. That didn't go very well because on feature teams, feature teams are pretty dedicated to moving their feature forward for their specific deadline and additional work wasn't super welcome. So we tried to tweak a bunch of knobs and my design director, Adam Bogner and myself, he and I went to our group of PMs and the VP of product and said, we're having a lot of trouble getting people to actually move issues forward when working on design system issues because the work is so sporadic and people's only real time to work on this is kind of in between waiting for other things and it's just so unpredictable that we have issues sit for too long, can we please have a dedicated time that I will block into people's calendars and don't schedule them into other meetings for that one window every other week?
And we got the thumbs up for that. So that's how we're proceeding right now. There are still some improvements to be made, but that's where we're at.
Chris Strahl: So when it comes down to the resourcing side of it, it really is about how do you set aside dedicated time to get work done and that block of time is something that you basically got alignment on around the organization to say this is dedicated to the betterment of all inside a product. Have people seen the value of that? Obviously they continue to give you time, but has there ever been a moment where people have been like, Hey, I need that person back, or Hey, this isn't something that's working for me, or is it kind of from the jump shown value?
Jamie Totten: I think that the value is definitely recognized internally because it is a volunteer. Again, people come in and out and that's just part of our process. At the beginning of the meetings, I've started to do a bit of a disclaimer like this is volunteer come when it is something that you're able to commit to, don't come if you can't, you're really needed elsewhere. Come back when you're ready. So sometimes our meetings like I have about 25 people probably on this meeting list, and sometimes there's 15 people, sometimes there's four or five. It really depends on what the product feature pushes are at the time and where people can be. But yeah, sometimes people get called back and I really do see the recognition we'll hear in company meetings about how the design system has really helped with consistency or sped up some development because we have these things that we can draw from into our features.
Chris Strahl: I think it's fascinating that you've been able to build a system that has recognized value without any real dedicated resources to it. I mean, like you said, it's a predominantly volunteer effort. There's people that come in and out. How do you actually roadmap things via inconsistency like that? I mean, you don't know week to week what kind of contribution you're going to get. I mean, you can assume some level of contribution, but within that guild structure that you've set up, do you all have a roadmap and a timeline that you commit to or is it much more loose than that?
Jamie Totten: It's pretty loose. We try to have a bit of a roadmap at the beginning of the year, but realize that as the industry has changed, as the world has changed since the advent of gen AI everywhere, it's really shaken things up where we can't really know for sure, oh, we're going to need this X, Y, Z component in the future. We really just try to focus on the highest priority and what we do in our meetings is those shift and you alluded to earlier as being a startup, priorities change a lot and priorities change within our design system. And really we try to think about what's the most important thing to be working on now. And so some of that is I attend lots of different team meetings to try to keep an ear to the ground, so to speak, as to what features are being built, where is there overlap.
I reside on the design team, so I have a lot of insight into what design's working on and try to keep my eyes on what's happening. But as far as prioritization, really we only want to work on things for our system that has a demonstrated product feature need. And one of the ways that we do that is using the rule of threes. I'm not sure if that's credited to Dan Mall, but that's where I originally heard of it. Making sure that something has that demonstrated need, you can kind of bank on it if you've seen it three times or so.
Chris Strahl: It sounds like the process is almost like Kanban where it's like, Hey, here we have this thing that we know is a priority. It's been validated via rule of three and whatever other rubric is associated with how many times you've encountered this inside of the organization, and then presumably some amount of resource or time allocation to it. It's interesting that you're able to continue to produce something that is like, all right, let's take the highest priority thing and let's deliver on that. And I assume that with a high degree of frequency that priority changes before that thing's actually done. Is it ever a situation that you find yourself demoralized by the constant change in your priorities and the investment that you make in one thing that ultimately ends up on the cutting room floor because priorities change?
Jamie Totten: I do smile at this. It's not too bad. We are really in the earlier stages. We have our tokens nailed and we have our preliminary foundational components, our buttons, our form inputs, et cetera, things like that. Our colors are all defined when we're working on something for product features. Where I may feel that demoralization sometimes is we can't necessarily, like other teams be ahead of feature development. So we will sometimes be building things to try to meet a feature being released and we'll miss it and we'll miss it because there isn't full-time dedicated people on it, and that's a little frustrating. So what that really looks like to us is we'd still finish it off, continue and then create an issue for our main app to bump our version of the design system package that we're working on and then go back and update the places where we've had to substitute out components for the ones that we're actively building or finishing.
Chris Strahl: Gotcha. So you're creating the thing, still finishing it out and then basically saying, Hey, look, we incurred a little bit of tech debt here. Let's flag that as something that we need to address at some point in the future.
Jamie Totten: Really try to do the kind of fast follow approach of if we've created some custom button that our button doesn't support and we want to update our button to support it, that if we were to meet the main app release schedule that the next time somebody could go and update that. We really try to communicate with the teams to be sure to update to the latest thing because you get all the new stuff. Right,
Chris Strahl: Right, totally. I think it's interesting that you're able to maintain such an aura positivity around this process because thank you. I think that a lot of people would find it maddening frankly, to not know exactly what I can deliver on a roadmap and to do things like miss a feature release because of resourcing challenges. I mean, that's the reality of where you're at, and I think that that's amazing that you've been able to build this model that allows you to not slowly go insane based on the work environment that's there. Tell me about that positivity and how that is maintained throughout this process, because I've never heard of a design system team functioning quite like this, and I think that it's pretty cool that it works. And so maybe give us a little bit more insight into the guilds and how that maintaining of positivity and forward progress really feels.
Jamie Totten: I won't say that I've never been frustrated by this. I certainly have. I think more last year I was more on the why can't we convince people of the power and utility and don't they want these things that we all want speed and consistency when in fact, of course they want these things too, but we just don't necessarily have the right team size and budget for it right now. So I think that honestly, I will give a shout out back to the Design Systems podcast. I owe a lot of my positivity from listening to this podcast.
Chris Strahl: Oh, thank
Jamie Totten: You. Yeah, I'm being totally sincere here. This helped me in a lot of the ways I hear from so many different people, from the great guests that you've had on, like you said earlier, coming from all different sizes of companies, you can go and you can look at their design system website. People really seem like they might have it all together. And then over time and the number of articles in the podcast I've listened to you really realize that nobody really has it all together and everyone's kind of figuring things out and it's just different types of problems at different levels of company maturity. And I hear people talk about the same things that I would face as problems like buy-in, organizational understanding, education resources, yada yada, and it makes me realize that this isn't really an us a clue problem, but rather a design system space problem and people are just figuring it out.
Chris Strahl: I think that there's a lot of great community that is out there, and by the way, thank you for the compliment. It's very nice. We are trying to feed into that community to create a space where people can raise these stories and these insights because one of the things that's abundantly clear to me is that there's nobody that quite knows the answers to a lot of this stuff yet. And design systems, as Gina is fond of saying, is fundamentally about people. And so the structures and ways of working together is oftentimes one of the big impacts that we're trying to figure out how to work our way through as a part of implementing systems. And I think that one of the reasons why I return to the concept of the guilds is that's an innately human people driven way of thinking about the work on the system. And I think that that's really cool. And so diving into that for a second, when you look at that guild concept, why does that work? Why does that really hit inside of that organization? And I mean this practice comes out of media, it comes out of advertising, it comes out of all these different ideas of how you get a collection of people together that are sharing some common interest in affiliation, but actually to get work done using it. I'm really curious about why that has been effective for you.
Jamie Totten: I think since I facilitate and delegate prioritize a lot of the work within the guild, I personally try to bring that positivity to the team. And because it's a volunteer group of people who have a shared interest and really do want to affect the same type of change that I want to affect or that we all collectively want to affect while working on this, just reminding people that we can affect positive change and this is something to be proud of. It moves a bit slower than an agile feature team, but we're really doing the best that we can with what we have. And it's okay if we have a large backlog. It's okay if priorities change, we know that we're leaving our system better than it was last week. Any incremental improvement that we can make, it's really approaching our work with a positive mindset, a systems mindset, and doing our best to be comfortable with that uncomfortable feeling of longer cycle times and increasing backlogs.
Chris Strahl: That's fascinating. I think that that's a really great takeaway where if you think about the constraints that you face and the structure that you've put in place, having a bunch of like-minded people that are just excited to work on something and keeping that error of positivity about it, I think that's really powerful and it's proven out by the fact that you have an effective team, even if it, like you said, doesn't necessarily move as fast as a traditional way of working, you found a way of working that is effective inside of the organization. And kudos to you for finding that in a place where having dedicated budget and resources was not going to happen. I think that's a really, I guess the word I would look for is a really wonderful embracing of this idea of how do I take the best parts of an organization and a community and build a team around it?
So when I think about this, I find a lot of parallels in open source communities where I think about the W three C working groups. I think about the Drupal community that I used to be a part of. We still am to some degree, and the idea that work happens on a volunteer basis, on volunteers' terms and on volunteers' timelines, but ultimately the work does get done and it's all about all marching in the same direction. How does that direction really get set? Is that something that's a guild driven ever as well where you sort of survey the people or talk to people? Is it like you or the design director that's really making that call of what gets worked on next? How do you actually think about what work you're going to take on?
Jamie Totten: As mentioned a little bit earlier, I kind of float between a lot of meetings and try to keep that ear to the ground. We of course have a design system guild Slack channel at our company, and within that Slack channel we have a workflow for accepting contribution suggestions. I guess that's one of two ways that we take input. So contribution suggestions, we ask people to just fill out a little form, what's the name of the component? Is it new enhancement bug? Is there urgency to this? And then describe the requests. Are we updating something that's broken? Are we creating something that new? And then typically we'll create an epic out of that. So the epic would include something like these are then under consideration, we'd create a few design tickets, design review tickets, engineering tickets, QA tickets, documentation tickets, and allow that epic to exist. And then that would be one of our discussion items in our next guild meeting.
Chris Strahl: Who's responsible for the creation of all that? Those artifacts, those tickets, those things, those requests, is that coming directly from the person that's saying like, Hey, I need this, or is that coming from some sort of central authority like you or somebody else inside of the org?
Jamie Totten: Well, the ones that get submitted through Slack, really I encourage anybody across our entire organization. I try to prop it up when I can, where I can in larger meetings and say, submit your ideas to this workflow, the actual creation of those issues. That's primarily me. There's another guy who's pretty dedicated about 80, 90% dedicated to John Clark and he works with me a lot. So when we see those submissions come in via Slack, one or the other of us will create a few issues in GitHub and then add it to our agenda for the upcoming meeting. And then I guess the other ways that things would get brought in, not necessarily our design director, but we'd see things in design work and then cross feature team work. Like we try to do design team check-ins on a biweekly basis unrelated to the design system, but looking over what's the emergent work and what are people focused on right now? Is there anything that could be considered within the rule of threes to be something that we should submit as a proposal for the next step in the design system? And then I guess that's where you can have things like jump priority queue when there's actually, like I mentioned earlier, a demonstrated feature need. We could jump priority queue a little bit, but we do have a pretty well sorted backlog right now. But yeah, it does change. We are flexible.
Chris Strahl: It's interesting because there's so many organizations on the larger side that are focused on adoption. How do I just get people to use the system I created? It seems like that isn't really a challenge for you, that you have a package that you create, that package goes into product, you have a good relationship with that product pipeline that basically says, Hey, there's a new version of the design system, go ahead and bump your version. But has that ever been a challenge as a part of this process to try to figure out how to actually get the product to use the things that you're creating or has that always been something that's kind of been in the background?
Jamie Totten: We do have kind of an unspoken mandate to use the things that come from our design system as far as where I hear larger organizations having those challenges with getting people to actually use their library or that set of components. We don't suffer from that so much, but we certainly do suffer from the standards and guidelines. So it's a lot of PR checking and talking to people and making sure that our internal communications are really clear. And that's a constant area of improvement for us is education, education, education and reaching out at the right time. So it's all still new and it's all still in fluxx, but we tend to take that same incremental approach to education as trying new things. We will periodically run surveys or actively seek out any individual contributor or feature lead and do a little bit of interviewing what works with our system, what doesn't work? People are using the things that are available because it's seemingly easier than building it new.
Chris Strahl: Yeah, I think that's cool. One of the things that's also interesting about this is when I spent a bunch of time in open source communities, one of the things that became readily apparent was the small details that show up inside of really highly curated teams. Those didn't really get much sweat in the world of volunteer contribution where very often, not even to the point of pixel perfect, but to the point of like, Hey, there's something that should be better defined or better structured or better laid out or better normalized or something like that, that maybe as a part of a more deeply curated effort would happen. You have some standards that you have to maintain, but ultimately people sweat details a little less. Would you say that that's necessarily true inside of the guilds that you've created or is there this real strong adherence to a set of standard and guidelines for what makes it into the system and what
Jamie Totten: Yeah, I think everything is still in flux. I think that we do see a lot of an innate adherence based on the maturity that we're at right now, where it's like our available components do the basic things that we need them to do, and then we layer on the complexity afterwards. So those can also be feature requests as mentioned in the contribution submissions.
Chris Strahl: So you develop a baseline and then that baseline evolves from there?
Jamie Totten: Exactly.
Chris Strahl: So you look at very clearly strip away all the stuff that isn't minimum viable or minimum lovable depending on your parlance, and really try to focus on what is the basic unit, and then from there you build, is that really effective? Do you find that people get a lot of value even out of those fairly minimalist building blocks?
Jamie Totten: I think we do. I think even to use, let's just use, I know you always are on about button components on the podcast, so
Chris Strahl: My favorite component to bash on
Jamie Totten: Your favorite component. Yeah. We certainly don't want to take the approach of, let's think of all of the possible varis and variations and bells and whistles that we could attach to a button and then build that. We are like, what is the absolute lowest amount of things that we can have in our button? Our buttons are huge. We do have a lot of variations in buttons, but we really do try to take the minimum viable approach and layer on complexity as it arises because our system is still evolving. Our design language is still evolving in a lot of respects, are building a lot of things new, and we have to let patterns organically emerge within our design language and within our front end before we can really take a step back and then normalize those and then build those back.
Chris Strahl: It strikes me that you have a really good relationship between design, engineering and product inside of your organization where it seems like there's a lot of innate kind of baked in trust. And then you also talk about things like PR reviews and stuff like that, which is not super rare for a designer to talk about those sorts of things, but also not particularly common to be thinking about release schedules and stuff like that for a design system. What sort of fostered that? Is that a part of the positive attitude and the guild mentality? Is that just the way that the organization has been structured and how communication works inside of clue what creates that bond between these different disciplines?
Jamie Totten: I think everyone is there to really do a good job working together. It's a great team. I think that you're right, we do have a good relationship between front end and design and product where kind Pull requests come into this. Prior to UX engineering at Klue, I spent a lot of time doing predominantly front end, so have a lot of understanding of front end being embedded on the design team. I've spent a lot of time working at different design agencies, so really getting that taste for design and being able to kind of be embedded with the design team and speak the engineering constraint perspective to design as well as going back and talking to the front end about design intent and adherence to, I guess just the intention I think helps build, and I mean, you can tell in some pull requests, some people spend more time reviewing for functionality, and we try to have at least one designer review pull requests, at least from a rendered perspective to approve the design changes that are in there. And where I would come into that is most of the designers are looking at it visually to see the rendered output. I would be actually looking to code to make sure that people are using the correct tokens and things. And I think that just over time the relationships have improved probably across all the departments because we all see that each unit is trying to really do their best to work together, and there's just such a great working relationship with everybody who works at Klue.
Chris Strahl: That's awesome. I think though, that's one of the huge advantages to smaller organizations is there is a lot more of that collaborative atmosphere. I think it's a lot harder and a big company to build a relationship between different disciplines. That doesn't start at some level of adversity, and maybe it did for you all and you've overcome that, but I think that there is often this sort of adversarial stance that exists where it's like design is like, well, it's just we build the thing and then it's engineer's responsibility to make it look like the thing we designed. Just how broken that mentality and adversarial that setup is for a lot of companies. And I think likewise, there's a lot of organizations that tend to be more engineering centric that always talk about how design lacks fidelity or they don't know how to build for what ultimately shows up in user land and the opportunity to overcome that by working together in this framework that you've established. I think that's really brilliant. It sounds like you all have a really great relationship that lets you build better product.
Jamie Totten: Yeah. Thank you.
Chris Strahl: Jamie. Thank you so much for being on today, sharing your story, sharing your approach. I love the perspective from the type of organization and the type of system you run and that sort of uniqueness of not having a bunch of dedicated people and being able to stay positive in the face of an environment that's a little chaotic and kind of constantly changing.
Jamie Totten: Thanks, Chris. I really appreciate being on the podcast. I love the podcast. I will continue to listen to it. Best of luck with all of your future guests.
Chris Strahl: Likewise, and thank you for being a super fan. You'd mentioned that you'd listened to nearly every one of the episodes, which I'm flattered and honored. Thank you so much for continuing to listen, and I appreciate you being on the show.
Jamie Totten: My pleasure. Thank you.
Chris Strahl: Awesome. Well, hey, this has been the Design System podcast. I'm your host, Chris Strahl, signing off. Have a great week, everybody.
That's all for today. This has been another episode of the Design Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @theDSpod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at Knapsack.cloud. Have a great day.
