Design Systems in Action: Collaboration Between Designers and Developers

Welcome to Even Keeled. I'm your host, Jon Kinney and today we're going to be talking about design systems and working with designers, both at Headway and at our clients. So with that, I'm joined by several folks from the Headway development team, including Tim Gremore,

Tim: Hello, everybody.

Jon: Chris Held,

Chris: Hey everyone.

Jon: Dan Diemer,

Dan: Hey there.

Jon: And special guests joining us from Minnesota, Noah Settersten. Welcome Noah.

Noah: Hey everyone.

Jon: So could you give us a quick intro about you and your background and what you do at Headway?

Noah: Yea definitely. So I've been a headway for a bit over seven years now Senior Developer now working full stack and have done some Ruby, done some Node, a little bit of Elixir and kind of helping out wherever I can.

Jon: So today, as we're talking about design systems, it probably makes sense to take a step back and define what that means for us here at Headway. We use Figma to create our design systems, but there's more than just the tool that you use. Chris, could you tell us maybe a little bit about generally what a design system is and what it means for developers and designers?

Chris: Yeah, absolutely. I think that this concept is probably a little bit easier to explain to developers just because of the way that we work and the way that we think about abstractions and the way we think about, refactoring things. So a design system is really a design broken down into its smallest components and then you expand there. It's sort of like you're creating Lego blocks and then you build into bigger Lego blocks, which become bigger Lego blocks, which become a page or become a view or become another component. So if you're familiar with React or even Angular, Ruby has, what are the Rails components called?

Dan: View components?.

Chris: View components. Yeah, anything where you're taking a piece of UI and breaking it down and isolating it... that's essentially what a design system is. And the, benefits of that, they're kind of obvious for developers and designers, right? It just makes everything a lot more consistent across designs because you're always going to be using the button. You're not going to be using the button on the profile page and the button on the homepage. It's the same component. There's props that change what it looks like. So again, like it kind of works with that React model or that prop driven model of programming. It makes that easier. It makes documentation easier, because you're only looking at one set of things. It's setting a single source of truth and like Jon mentioned, we use Figma to set that source of truth for us.

Jon: So speaking of Figma, there's the concept of a design system in code, like we just talked about, if you're using a front end framework that already has components, it's kind of a one to one mapping of, the design system being broken down into those various components. But, one thing that's somewhat newer is the concept of a design system inside of the design tool itself, and that's been a really big help for us here at Headway as we work with designers, both on our team and on other teams, because we also can train folks on how to use Figma design systems as well. We've got a lot of YouTube content on that, if folks are interested, we can link to that in the show notes. How has that helped from a development standpoint, being able to create those design systems at a more modular, actually almost code like way inside of Figma.

Chris: Yeah, that's been huge because it's like speaking a shared language because I know that we're all old enough, to remember Zeppelin or maybe even before that, you know, just Photoshop files of here's what the layouts look like...

Jon: Yeah. Good luck. Slice it up.

Chris: Right. Yeah, here's, you know, copy of final today's date three dot PSD, figure out how to make this into a functional app. So if it's laid out in a way that already makes sense to you, like that mental model becomes a lot easier to reason about. When you see all the components laid out, it's as simple as like, you're going into Figma and you're saying like, okay, here's what my components are named, here's where they should be placed in a directory structure. I can do all of this work without having to do that mental load of translating from the design into coded components.

Noah: And I think it also really helps with consistency to, you don't end up with bespoke pages that are designed separately with slightly different font weights or styles or colors. You're using ideally a shared set of tokens, you know, shared set of typography styles, that sort of thing across the whole build of your application or your site, so that things just remain consistent. If you need to adjust a style, it can impact multiple places within your design because it's based on that shared pattern in the design system.

Chris: And not only is it less code, but I think it really shows in the overall quality of an app at the end of the day, where like you see everything's consistent, everything lines up. It really improves the way that your site looks and the way that it performs because you have less rework to do when you have to make a change.

Jon: So it sounds like there's some immediate benefits from leveraging that system on both the design side and from an implementation perspective with development, but is that the end all be all the Holy Grail if you're using a design system in Figma and you're implementing it in development, does that solve every single problem or are reviews and things like, testing and QA still really important?

Chris: Yeah, I think that reviews and testing, that's always going to be important. It's just, you're going to catch less things. That's kind of the goal of doing all of this, of doing anything, of doing any kind of refactoring or any kind of abstraction is you want to lower the impact of changes. So when you do this, like you have fewer things to change when something changes, and then that means there's actually less to QA, there's less to test , so you're speeding up the development process.

Dan: Yeah, like Chris said, when you're thinking about it from like that Lego brick perspective, if a component is just a handful of smaller Lego bricks, it's a lot easier to review those at the time that they're being built and changed, than it is to review the entire thing, holistically, top to bottom. And so it can really speed up and improve that pipeline of getting quality code out the door that matches what the designer and the stakeholders expectations are.

Jon: So, I mean, it sounds like design systems are really the best possible way to design and develop complex web applications or mobile applications. Does it make sense to use a design system 100 percent of the time for any design and anytime you're going to be implementing that design in code or there times where it might be overkill. Have you had experience with any of that, Tim.

Tim: Yeah, that's a good question. It's not meant to be a one size fits all for every project. The scope of a project could be defined by time available. It could be scope in terms of the width and breadth of a feature set Maybe it's just the availability and the capacity that your team has to work on that given project. If you're limited with some constraint time team size, you might just not have the capacity for that. You might need to forego the perfection of a design system and build out the application or the feature set, knowing that you just have a deadline to hit. And so there's, other considerations in play, but we've certainly found software to be more maintainable, more effective, more predictable when we've been able to apply a design system to the build.

Jon: I've recently heard some arguments against using tailwind and how people just don't understand the separation of concerns anymore. And if you put everything into your CSS files, you can change the design and the layout of the site without having to impact the HTML. And I'm not sure that I buy that.

Tim: So lately I've been using more Tailwind to update our Birdseye application and Birdseye has a long history. There's a mix of- it's all Tailwind, but there's a mix of some custom styles and separate style sheets, and then the majority of the styling is done via the utility classes that Tailwind provides in a Heeks template right in your HTML. What I've found is that there's so much ability with modern CSS that is available through Tailwind, that I've been able to iterate on those pages by delivering new features or by expanding on the existing feature set within Birdseye surprisingly well, even though, like I said, the code base is a few years old at this point, and it's a blend of external style sheets and class utilities right in your HTML. It's been very straightforward, and as I'm making changes, because there's a lot of history to it, it would be very easy to create a regression, right? It'd be very easy to cause something to break as I'm trying to improve on that very thing that I might be breaking. But the advantage of having well defined styles in Figma in a design system, though, that design system is loosely defined for this particular project. Having those definitions in Figma, translating that into utility class with Tailwind, and then applying it in Birdseye, I can see very clearly in a Git diff what changed. So it's quite easy to look at that and see, here's specifically what changed. I know that utility from Tailwind is specific to this CSS function, and it's been very well defined for me as I continue to iterate on this, what's changing, and then that helps me avoid the unwanted regression or side effect.

Jon: So I'm curious you're talking about heeks templates, HTML front end side of a full stack Elixir application. I know we also do a lot, like Chris mentioned, with React, and in Figma, we have the ability to go to the parent component and view the design system, really, from its most atomic level, being able to view on a single screen, all of the different building blocks, those Legos that Dan mentioned that can build up any given, organism or molecule in the design system that ultimately then become portions of a page and truly a page at the end of the day.

One thing that's been nice, In working with our clients on React applications is the ability to take that design system at its atomic level in Figma and create a replica of it in code at that same atomic level in a tool called Storybook. Probably most folks have heard about Storybook and let's get into Storybook in a second, but I'm curious on the non React side of things, the non JavaScript heavy side of things in full-stack server rendered web applications, Tim , and here we do Ruby on Rails and Elixir, um, specifically with Elixir, do you use a Storybook like framework to help provide that same atomic level of design system inspection, at the code level ?

Tim: Yeah, that's a good question. So there are Storybook equivalents in the Elixir community. In the, Ruby Rails community. And yeah, for Elixir live Storybook, we're not using that with the Birdseye application, but Noah and I started using that for our MediCode application, for our AI/ML exploratory product that we've been building. And Noah, I'd be curious to hear your experience with that so far, but it feels very mature, given how young the live Storybook library itself is. It feels familiar coming from Storybook In the JavaScript ecosystem so curious though Noah if you've experienced that same level of benefit, if you feel it's on par with what the JavaScript community uses?

Noah: Yeah, I'm not sure I have as much to say on the Elixir side exploring that, but I've definitely done more on some of the alternatives for the Ruby side of things using View Component, which I think is put out by GitHub. There's another tool called Lookbook, which is like Storybook, but for View Components. And so it allows you to see the individual atomic or depending on how it fits in the design molecules or larger pieces individually and independently and compare those and matches the design and see some interactions there. So it seems to work pretty well, pretty similar to Storybook. You know, Storybook being maybe more of the original, there's, there's a lot of add ons and different things you can get for Storybook that maybe don't exist outside of that, but the core feature set anyway, seems to be pretty similar for like view components and lookbook anyway.

Tim: I think part of our interest in it is because we've seen the benefits on the JavaScript side. The interest being using that same approach in Rails or in Elixir, but we just haven't had the length of time, leveraging those tools in Elixir or Ruby to fully vet it. But we probably all agree that you can feel some familiar promise in that space, like we experienced with JavaScript.

Jon: Yeah, so Chris, I know you have worked extensively in Storybook on multiple projects. One of the projects you were on for a very long time, infamously leveraged Storybook until you just abandoned it entirely. Is that a common thing that happens as software matures and it's difficult to keep up the design system in practice. Or is it is it really something we should strive for to maintain? And go into the differences between how that worked for you at that prior project and how it's working for you as you implement a React design system at your most recent client.

Chris: Yeah. So I can pull the Senior Developer card and say, it depends. So it, depends a lot on what is your, goal with the Storybook. If you want to host Storybook somewhere and have this as documentation for developers down the line building products and implementing your platform, then you should absolutely keep Storybook up to date and you should make sure that it goes along for the ride. If you're using it as, a way to get a UI out there for someone to look at until you have the app built, then you probably don't need to keep it up to date once the app's built. So it has a lot more to do with, the goals of your organization, and how your business runs. So if your design system is going to be a platform that's going to be used in multiple applications over the course of three to five years, absolutely keep that up to date. You have to essentially. But if your goal is to get something that you can show to stakeholders to get approval, or to get handoff and say, yep, this is good to go, we can keep going, then use it as long as it's helpful for you. And then when it's not, you know, don't maintain it and if you need to bring it back to life- cause this happened at a couple of places I was at a few times where we would build up Storybook. We would forget about it because we'd get kind of hard into that app development. And then we'd start a brand new feature or even a brand new app that uses a lot of components from the original app and then we'd bring Storybook back so we could get back to that kind of quick prototyping phase. So whatever works best for, your team and your organization and lets you move fast, then continue to do that.

Jon: Yeah. I like the, it depends answer. We hear that as well in unit testing and integration testing, more specifically in unit testing, where there's folks that say TDD every single feature a hundred percent of the time you have to, or you're not going to design it well. And there's people who say that's a waste of time, you don't know how to test what you don't know how to build yet., just use integration tests. Obviously, I think the truth lies somewhere in the middle. You can get some benefit from test driving features when it makes sense, but at the same time really smart folks who've done testing for a very long time will also tell you just because you wrote a test to help inform the implementation of the feature doesn't mean that that test now has to live in your test suite forever.

So I think that's, a lesson learned from decades ago, most likely that we're now kind of relearning or remembering, hopefully, as we develop components in Storybook and leverage other, technologies that help us collaborate and break apart these portions of our app into their more basic elements, you know, might be useful at the start, and it might not always need to stick around, especially if it's a proof of concept or, like you said, a way to get something in front of a stakeholder, that's easier than composing that entire page or copy pasting a bunch of things into multiple files, so yeah, I like that answer quite a bit.

Is there a way to help folks view a Storybook like platform outside of their local development environment? Do you just go to like slash Storybook on the production app? What have folks used to host that?

Chris: So right now we're using GitHub pages to host our Storybook. It's really just a static bundle, so you can build to just a static site. You could push it to an S3 bucket. You could do anything with it and then route DNS where it needs to go. What we've been doing, what's been really successful, has been each branch that gets pushed up and a pull request gets opened to main, we build a Storybook instance for that. So we can quickly demo any components that were built. We can get a design review and then before that gets merged into main, we're confident that it's working and it's doing what it's supposed to do.

Jon: Have you used Chromatic before? Is that a portion of the hosted experience with Storybook?

Chris: Chromatic is a visual testing tool. I think we used it a couple of years ago. We haven't used it a lot lately, and I think that it's very useful for snapshotting. when you push up a branch, it'll tell you exactly what components changed. Because it takes a picture of each component in the Storybook and then it takes another picture of each component in the Storybook with the new branch and it'll tell you the diff. So very useful there to make sure that you don't accidentally wreck something that you weren't intending to. So that's the, main use of Chromatic. But to your point, I think that you can, host through Chromatic as well.

Jon: Nice. So Dan, on the mobile side of things, what's the story with Storybook and design systems? Is it vastly different than the web or do we see a lot of parallels? Are there some of the same tools that get used? How's that look?

Dan: Yeah, it really depends on how you define mobile. So, for us, that means a variety of things. At Headway, we do a lot of React native and more and more turbo native, which is where, you're using web views and the turbo framework that came out of the Basecamp group, for Ruby on Rails, but it's not, explicitly stuck in Ruby on Rails it can be used with a variety of other platforms and then also native, native, right? So Swift and Kotlin, SwiftUI, Jetpack Compose, that kind of stuff. What we've found, at least on the React Native side, it's probably the easiest to get Storybook set up in a one-to-one experience. However, the tooling is not exactly where it would be on the web and so there's a lot of maintenance required to keep it working. And we used it early on with a project to really get what Chris was describing is like some UI in front of the client, before building the whole app, because a lot of times it is useful to be able to show some progress and show the implementation of the design system and a set of designs in Figma without having to, like, just build an entire scaffold application for those purposes. And so we used it quite a bit for that early on and then abandoned it later because maintaining it was not worth all the extra development headache of keeping it going and keeping it working while also trying to deliver features to the client.

When you talk about on the native side of things, it's a little bit different. The tools themselves like Android studio and Xcode actually have really good functionality built into them to do this kind of stuff, to do like previews of components but as far as getting them then outside of, that experience. To maybe have like a developer designer review session, I've personally not worked with any tools that really automate that. And so I would love to know more if there are. I just haven't found any. And I really haven't ever had a need for them either on native projects. It's always been pretty straightforward. Once you've got the app in a place where your designer can just get it. It tends to be the easiest way for them to like, look at a feature and be like, yep, that looks correct or no, or just get on a call with them and show them. Usually that would come up during like when we do a share out session, we would be able to like have that conversation and, be able to, establish whatever next steps would need to happen if a design needs to be tweaked.

So I think on the mobile space, it's a little bit different and probably just not as worth pursuing, at least. So far, that's what we've found.

Jon: Now, Objective-C for native iOS development leveraged a technology called Storyboards, right? Which is different than Storybook. But did it help in that regard somewhat where you could visually see the application a little bit more than with SwiftUI?

Dan: Yeah, I think so. so I guess like to clarify, Storyboards are not explicitly tied to Objective-C you can use Storyboards with Swift also. The way Apple has really set up their UI tooling, there's kind of a dichotomy where you've got Storyboard focused apps and you've got Swift UI focused apps, and then you can also mix and match those two things. So I think because it started so visually, there really wasn't a tool needed to do like, let me be able to export all of these things and, have them where you can see them because we can just open the app and you could see them, right? The designer could have X code, pull the project down and look at all of those things specifically. And SwiftUI provides the same kind of functionality, the preview built into SwiftUI can give you a live preview of whatever your component is. And then a developer can also set up a variety of scenarios for a preview. So preview might show, a button in multiple states or things collapsed, or what does this look like in light mode and dark mode?

So I think the tooling is just more built into those IDEs on the mobile side. And Storybook on the web kind of fills that role that was a little bit missing from the web where instead you would probably have to build like a kitchen sink kind of page that's just got here's every component we have, and they're kind of just dumb and you can just look at them and not interact with them.

Jon: Right. So the implementation side of things can vary based on your technology, but I think it's still really, really helpful to have your designer. implement a design system and a design system framework inside of the tool that they're using like Figma. And we talked about this a little bit previously, but what is it like working with a designer who's leveraging a design system?

Well, for example, we have one at Hedway called Shipwright. And I know that that has helped jumpstart quite a few projects. Tim, have you been able to work with Billy or anyone on our design team with a shipwright Figma design system as a starter?

Tim: On internal projects I have. So we've explored all the benefits that we've been talking about around design systems, not only for the design team, but how they help speed up improve the quality of product the dev team is building. All those benefits we've been looking at how to automate that, And so we've been working with our designers on automating the extraction of design tokens of those design specifications, and then being able to ingest them, into whatever, product we're building, whether that be web, whether it be mobile, looking at automating that process. So because you start to form definition, very specific specification in your design system, then you can begin to, like I said, build, automation around it and there's some additional benefits then that come from that, because you eliminate the possibility that as you're copying and pasting a color, for example, or, uh, or some spacing or, or a font definition from Figma into your application. you may copy and paste the wrong thing, but if it's. Automated. you minimize the risk of error

Jon: Yeah. So that collaboration, you're not saying to replace the interaction of developers and designers with full automation or the ability to export from Figma to code directly. Although there are tools that do that, Tim, right? You're saying that being able to have a really well established design system In Figma, that can then have some aspects of it automatically flow into the code really helps that collaboration between the developers and the designers so that you're not having to measure things in Figma and, you know, check out what font it is specifically, some of those baseline elements already come for free, and then that way you can work together more to build out the key screens.

Tim: Yeah, exactly. part of my goal, and I think what we realized when we leverage a design system working with our designers is that it actually empowers the designers to define things more clearly, if that makes sense. There's less subjectivity in a developer looking at a design and saying that looks like 16 pixels. Whereas when a designer is specifying those exact measurements in the design system, we eliminate that subjectivity and so in a lot of ways it empowers them to be more of an authority in what they're designing and what the end product will be. So to answer your question, actually think it strengthens the collaboration with designer and developer, more so than it does isolate and eliminate the human interaction.

Jon: Right, and you were speaking about working with our design team on some internal projects where we have all the flexibility in the world to run Headway's process and to be clear, sometimes that does happen on client projects as well, where we get to work cross collaboratively amongst design and development, but a lot of times our Clients will also bring their own design team.

And I know Chris and Noah, you both are working at a client right now with a very talented set of designers and product folks that are defining a lot of these things that we might otherwise typically do from the Headway side on our design and strategy team. How is working with the design team at your current engagement different than perhaps what Tim was describing in working with our designers internally?

Noah: Yea Actually, I think in this case, the process is very similar. Probably the big difference is they had a very clear vision for the design of the application for functionality and features and things like that, that we had to take the time to be able to learn and understand so that we can make sure we're headed the same direction, which would be a little different because they already had a lot of that vision in place.

As we started but the actual day to day collaboration is, pretty similar. they're using Figma as well. and they have a real clear design system built out there. So it makes it easy to follow and to work from.

Jon: So is there a method to the madness that helps designers and developers work more seamlessly together? Chris, is there a flow that you need to follow a recipe, so to speak? Or, does the order not matter as long as you're using design systems on both sides of the fence?

Chris: No, I think having a design system is, is hugely helpful no matter what you're doing. because it is a lot of design documentation that you get, up front. But I think main difference that we try to, champion here is, having designers and developers working actually together for the duration of the build. A lot of times at, larger enterprises or even other businesses, you'll have an agency come in, they'll do design, they'll give it to stakeholders, and then there's a fence that it might be a fence with a couple of gaps in it. It might be a brick wall, and then you give it to the developers. and that makes things really difficult. So you can have the best design system in the world. There's still going to be places where intentions aren't clear, or you're not sure how an animation is supposed to work, you missed a hover state, things like that. Those are things where you really need to be able to just have a quick conversation with a designer. So I think the thing that we like to do is having stakeholders, design, developers working together throughout the project. And that sounds a little bit messy, but one of the things that's important for us is, having trust between the three teams that everybody generally believes that everyone's going to do a good job and do their best. and we have the designer and the developer, they're working very closely together and the stakeholder is kind of overseeing everything.

And by stakeholder, that could be a startup founder. That could be a business analyst, that could be a director of a certain department, whoever it is, they sort of set the expectation, they provide documentation, they work with the designer to create the initial design, they work with the developer to make sure it's implemented properly, but the designer and the developer really hold the lion's share of making sure that this gets done to the liking of the stakeholder.

Jon: So how does that work when you're remote and asynchronous? Obviously we do standups and we can get on design reviews and things, but have you found that Figma's prototype mode is sufficient to highlight, you know, a drag and drop example in a design system implementation ? Or is it really necessary to get on a Zoom call with that designer to review the interactions of that particular workflow before going into development?

Chris: I think it depends on the complexity of the component. So sometimes the designs are annotated enough where it's obvious what we need to do, or it's like, this is the loading state. This is the error state. This is when fields should be disabled, things like that. But if you have a really complicated component, like I was just implementing a bottom drawer that has a lot of different scroll interactions and breakpoints, and before I started, I, Got on a call with the designer and we spent a couple of minutes just talking about, okay, here's kind of the main concepts, right? Here's how I want this to work. And I think that was really helpful when taking the broad strokes at that component at the first try.

Jon: Yeah, I like that. It makes sense to work together collaboratively in real time when you're reviewing more complex interactions like that. I do think a design system can help teams work more asynchronously, which is a nice benefit of being in a system that's really well defined and able to be broken down into those small components.

Dan: Yeah, I think it helps you not have to waste time getting a bunch of people into a room or into a call to go over something that's a little bit more minutiae, right? If it helps you get 80 percent of the way there so that you really can spend that time together collaboratively on those things that are really complex, then that's going to be where the value is.

I think back to a client we had where, we were doing some charting of, health data and the overall design system that they had got us the answers that we needed to at least build the component. And then when it came to how, does this actually work? How does time affect this component?

And how does new data coming into the chart, work its way in and animate in that's where the real value of that one on one collaboration with the designer was not with him saying, Hey, I think that. You know, this should be that color blue and it should be a little bit bigger because that's all, information that can be communicated so effectively asynchronously through a tool like Figma and by implementing a design system.

Jon: And are those interactions, those nuance that, that Chris spoke about with the bottom drawer and some of the scrolling and things, are those more frequently encountered in mobile, I would imagine. And are there aspects of a design system in Figma that help highlight those mobile interactions, or do you just rely on the standards that have been set by the various vendors?

Dan: Yeah, I think it really depends on, what the intentions of your designer are. So for us on that particular project, our designers were pretty clear about, Hey, we don't want to stray from how Apple does this or how Google does this. And when we do, we're going to talk about it. And so that gave us a lot of freedom to look at just the designs that they have given us, implement the design system and then lean on the system defaults to do all of the things that they should as far as like navigation transitions and tap animations and things like that where we really didn't have to like reinvent the wheel, when there were places that we would need to do that, we were able to have that really effective communication starting usually as like a figma comment like, Hey, talk to me when you guys go to implement this so that we can make sure, that we can get the ideas across because I think there's also a little bit of diminishing returns for a designer to go in and hand animate all of these things in figma through a prototype. Sometimes I think it's effective for documentation purposes, but if it's like a really complex thing and they want to make sure it's one to one. But sometimes it's probably just as fast to get on a call. Especially with the way that the mobile tooling works, you can work really collaboratively and share your screen and make some changes and dial it in with them live versus shipping code back and forth.

Jon: It's one of those aspects of, you know, a startup will oftentimes get the five employees all in the same room so that they can move really fast together. We can do that virtually as well through Zoom and other aspects of the real time collaboration in Figma. So I think that's perhaps one of the benefits of working with a team like us at Headway, where we're fully integrated between design and development, and our client can jump in there too, we're all likely to be in the same time zone that allows us to do that during the day, so it can be a challenge. I think if you're, uh, in an, you know, offshore type situation where a hundred percent of your design needs to be communicated asynchronously, I suppose in those cases, and we've done this as well, just as we finish up features, you could record a loom. loom is a tool for recording video that we frequently use.. That's, I think perhaps better than animating something in Figma. You could speak to what it is that you need versus needing to always jump on a call. so perhaps one way to mitigate that potential, downside of needing to be asynchronous with offshore.

So we've talked a lot about how a design team can have a very strong process and a very strong system in place. strong, maybe isn't the exact right word because it's flexible at the same time, but, a well organized. system in Figma that allows for changes across implemented components in a very easy, simple way. And we've talked about the fact that developers can leverage that system when they go to implement it. We've talked a little bit about the collaboration between those two teams... but what about when it comes time to review the end result. Is that something that we frequently bring the designers back into Noah? I'll ask you because you recently have been working with both our internal design team as well as the external design team on your current client that we talked about, and I think that's You all have a pretty robust review process at your current client, not that we don't at Hedway, but how is that different, and what role should the designer play in the QA process to get that feature shipped?

Noah: I think it's really valuable, especially as a developer who doesn't have a lot of design instincts compared to a designer to be able to have someone who worked on the original design or has familiarity with to come back and review that in a live application, just because no matter how documented the design system is, the developer may make mistakes or may just have to make interpretations of different pieces. So we've done it a couple of different ways. Sometimes it could be you have the application, you have the pages up on a staging server or development server, and the designer can go and can interact with them, view them that way. The current process that you're kind of speaking to, we have Storybook that gets created for every PR and the designer can go and just click that link and see an instance of storybook with the changes from that specific PR. And we can call out, which components have changed or which components are new and interact with them right in there. Storybook is also nice because you can set up controls. So you can set different variants or variations of each component. So if there are specific types of, styling or things like that, that need to be toggled or adjustable. You can put that right in storybooks. The designer can see how those different pieces interact together- you know, if I turn this piece on and turn this one off and adjust this side here, does it still look the way I expect in that specific combination? So they can do a lot of that in Figma, but it helps to see that kind of live in Storybook once it's built out to make sure everything is interacting the way that it was envisioned originally.

Tim: Noah, one thing that I know you and Chris have experienced is how to manage an additional step in the pull request review process. Because you're now asking a designer to sign off on what typically would be a code review, a developer activity. How are you managing that interaction with the designers so that your list of pull requests doesn't pile up and you don't end up with just a backlog of branches to manage?

Noah: Yeah, I think that's what a process is real project dependent. So in this specific case, we're building out a component libraries were building out the pieces of design system. So it's really valuable to have design feedback early on. In other projects, we've had it where, you know, before we have features ready for demonstration to a client or delivering that way, a designer could go and do QA of the whole thing, post PR, post merge, it's already deployed, maybe on a testing environment. In this specific case, there's a good advantage to really dialing in the components in the design system well, because they're planning to use this component system in the future and really get it honed in nicely. So we have design review as part of. before, or mixed in with other developers doing code review and it, increases the cycle time. It's just kind of a trade off there of there's usually more iterations to go back and adjust and adapt things to design feedback, but similar to developer feedback on that. You just have another person who's doing another set of reviews.

Right there. And so the main key there is maybe just having open communication and fast, cycles there to be able to go and get that feedback and act on it without things waiting too long. Inevitably, just like with the code review, you'll have something that you're waiting for feedback on. And so you'll start working on something else as you're waiting for feedback or waiting to get responses and reviews there.

So it might be product dependent, but you're trying to find that good balance of getting the amount of feedback you need, getting things reviewed in a thorough way. Well also still being able to move forward at a decent pace in that context, which too much, it's probably dependent to the needs of the project.

Tim: is your sprint planning and just client expectations for the timing of when work is going to be done? Have you been able to keep up to those expectations and is everybody content with that additional step in the, review process?

Noah: Yeah. That's a good point. in this case, yeah, It depends kind of on what the client is looking for, what their needs are. And in this case, having that thorough design reviews is a valuable addition. To building out these components and getting their library in a good spot. So makes sense to invest that time.

Now, in other cases there may be a need to move quicker to get some features out there, to be able to validate it or build out an entire app to see is this prototype going to work or maybe do some user research with it. In that case, it maybe wouldn't make as much sense to invest this time here at this stage. But in this case, it's a valuable thing.

Chris: Yeah. I also think there's, there's levels between that, right? Like there's no design review over here, and there's full design review, pixel perfect over here. You can meet anywhere in the middle. and I think we do a pretty good job of learning to compromise, right? If our designers know that, sometimes, the budget and timeline necessitates that we, take on tech debt, in order to meet a timeline, or it can go the other way where if, you know, a designer wants a feature a certain way and we're like, well, we can use this library and it'll look 90 percent of the way of what you want, but it'll save us a week of development time, then, you know, they're very quick to be like, yeah, let's do that. So I think that's an important part of it too, is just like people are humans and they're able to make concessions.

Jon: So, Chris, I know you have an opportunity coming up speaking at a conference called THAT conference. And if folks haven't heard about that conference before, it is a conference called THAT conference, which is quite confusing. But a friend of ours, Clark, puts that conference on both in Wisconsin and in Texas and we've spoken at THAT before as a sponsor, but I think you are our first developer to submit a talk and get selected, so pretty exciting to have you representing Headway and talking more about design systems coming up. Tell us more about that.

Chris: Yeah. A lot of that is going to touch on some of the stuff that we talked about here. Basically talking about how you can empower your teams to build, better products, right. By, working with designers and developers more cohesively. We'll talk a lot about that bi-directional communication, right. Talk about Figma, talk about Storybook, how we can make those two tools work together. Talk a lot about design systems, talk about design tokens, how you can use those, so it should be good. I'm excited.

Jon: Nice. All right. Well, appreciate the conversation, everybody. We do a lot with design systems as obvious by our discussion here today. If you're interested in learning more about how to build your own design systems, we have courses available as well as content on YouTube, and we'll link to both of those in the show notes, but check out https://headway.Io for more information, thanks everybody. Have a good rest of your day and we'll see you next time.

‍