This week, Dan Neumann is joined by a first-time guest on the podcast, Seth Jacobs. He is a Sr. Director of Experience Design at AgileThought.
In this episode, Seth talks about technical excellence, from a design language and design system pattern to help the audience understand how these systems and patterns can be started and used, as well as the implications of evolving them over time.
- What is a Director of an Experience Practice?
- The role of an experience practice director is to approach design from an architectural level, how the design teams work together, as well as contemplating what has been delivered
- A Director of an Experience Practice supports teamwork
- What are some of the places where technical excellence really pays off from an agility standpoint?
- Documentation has a huge role on the technical side, how they are taking them and how they are being shared among the team
- The Storybook is a way of having the collection of components or controls that are used in an application, that becomes a visual library for everyone across the teams to use
- How is standardization balanced to avoid getting stuck?
- The design system is really the collection of several different things including a component library, and how all these components are arranged into patterns
- The benefits of the design system are clear when all teams have a shared understanding of what patterns need to be implemented in which cases
- How is the feedback received from people who are working from the design patterns in order for them to continue to evolve?
- It depends on the size of the teams and how they are structured
- AgileThought counts on a core team that works with the designers and through the design thinking process to then feed these processes on the other teams
- Why are the elements of a design system so valuable? How do they pay off?
- One of the biggest payoffs is for the users
- It makes sure that consistency is being preserved
- Seth talks about different design language tools
- How should organizations react to changes?
- Go back to the original user’s journeys and the goal of the user to see what kind of potentially systemic effects that change could have
- Remember, the most important thing is how much value you can bring to the business or the user
Mentioned in this Episode:
Transcript [this transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan Neumann and today I’m excited to be joined by a first-time guest on the podcast, Seth Jacobs, who is a director of the experience practice here at AgileThought. So thanks for taking some time to join Seth.
Seth Jacobs: [00:32] Thanks for having me.
Dan Neumann: [00:33] Let’s uh, let’s maybe start with what, what is a director of an experience practice, um, because, and tie it in a little bit to our topic today, which is really going to be exploring some of the facets of technical excellence and how it enhances agility. So if you can just introduce yourself a bit.
Seth Jacobs: [00:50] Sure. So, um, you know, at a, at a high level, a lot of the kind of processes and the way that we approach a UX design at AgileThought are things that we try to think kind of very deeply about, you know, how do we approach the problem from an architectural level when we have these larger teams that are put together, how does design work in that? Um, you know, how those design teams work together on those kinds of projects, um, and also, you know, what, what do we deliver? You know, we’re working as a team, you know, what do we deliver? How do we deliver it as a part of a team? You know, we don’t, we don’t work like, um, kind of a traditional design agency where we’re off in a silo and passing designs, over development teams. We’re a part of the, uh, the, the teams. So, you know, it’s really kind of my responsibility to make sure that all those things really work together well, we’ve got a good method for how we approach those things and really kind of supporting the team members in doing that. And also, you know, I’m, I’m, hands-on as well. So I’m also doing, uh, those things, uh, as a part of those teams as well. Um, yeah, that’s, that’s kind of the, at a high level that would go in there.
Dan Neumann: [01:59] Awesome. Yeah. And I love that, you know, I have probably taken shots at ivory tower architects in the past where, you know, somebody, they don’t do anything, but draw little diagrams on the board and then inflict those on other people. So it’s awesome to hear that you’re in there getting your hands dirty still.
Seth Jacobs: [02:15] Yeah, for sure. Yep.
Dan Neumann: [02:20] One of the agile principles is that continuous attention to technical excellence enhances agility. And I’m curious before we get into some of the, the hows around that, what are maybe some places where you’ve seen technical excellence really pay off from an agility standpoint?
Seth Jacobs: [02:37] Yeah, so, I mean, I think that really ties into, so from, from my perspective, I’m always looking at things from, you know, the design, it, you know, how, how, you know, when we’re working with developers a lot of the time it’s, you know, how are they taking, what, what it is that we’ve designed and putting into action. So that’s kind of where we’re looking at things from, and, um, you know, there’s things that certain designers that are looking at that, or at least they’re kind of crossing their fingers for. Uh, they’re going to create a design and a team takes it in. They really want the interpretation of that design to be pixel perfect. They want it to look exactly like how they created it. Um, and yeah, and rightfully so, because it’s something that, you know, it’s been shared with everybody it’s been bought into it everything. Um, but I don’t really, I mean, that’s a great goal to have, but I think there’s other things that are, that are far more beneficial to the team, uh, on the technical side, um, that has an impact on design as well. Documentation is huge on, uh, the technical side. Um, and when I say documentation, I mean, you know, when, you know, creating designs and that’s being consumed by development teams, how are they taking those things and how are they sharing them across their teams? Are they taking note of who’s done what? Um, uh, how, how it was done. Was it done the correct way? You know, are they pulling in 10 different, um, UI libraries, uh, to do, you know, the same thing? You know, how are they doing it? So, you know, I think a good example of, or at least I’ve seen in the past is teams starting to use things like, you know, there’s a tool called storybook. Um, it, storybook is basically a way for you to, um, have a collection of components or controls that are used in an application. And it basically becomes this visual library that everybody across all the teams can reference and use, so that when they’re all looking to bring things in, when they’re working on their particular feature or whatever it may be, um, there’s a shared kind of knowledge base of how that’s occurring. It’s not just people, you know, looking in the code base and trying to copy paste stuff and hoping that that pays off. Um, it’s having something, something that’s surfaced and visible to the entire team and, you know, I’ve seen cases in the password that wasn’t, that wasn’t, that wasn’t always the case. I don’t know, 10 years ago people were kind of on their own. They didn’t necessarily have those kinds of pieces of documentation, uh, available to them. And you know, it, it creates a little bit of a problem because then you start, you know, if something goes wrong with one particular part of the system, but it was implemented maybe three different ways for the same thing. Um, you know, it becomes a little bit of a nightmare tracking down, you know, what’s going on. So, um, I think that’s been incredibly beneficial for a lot of the teams and that is that particular instance and that kind of thing, that storybook tool is just one instance of, or one part of, kind of a larger, uh, thing that you can look at, um, from, from an implementation standpoint, that’ll help teams be a little bit more efficient.
Dan Neumann: [06:03] So I think what I hear you describing is, is paying attention to those shared approaches so that people aren’t out reinventing the wheel. I know when I, when I used to do software development a long time ago, the reusability is been a concept for a long time, but there was always that why are there so many calendar controls that was kind of always the quintessential example, everybody’s got a different calendar control and, uh, you know, if what you’re talking about with the delivery team, um, you know, and maybe a scaled approach, you can’t have everybody solving the same problem, but you can, it’s a bad way to live, have everybody’s resolving the same problem. And so sharing some of these approaches across and, and tools like storybook, enabling that when you, um, when you’re approaching teams with some of these ideas for, um, using a tool like storybook, like here’s the way we want to do things. How do you balance some of the, uh, the need for standardization with having some of those things emerge over time? Cause I’ve seen teams get stuck waiting for the enterprise, whoever that is to make a decision about an architecture, about a UX decision, whatever they get stuck waiting. And so I’m kind of curious how you balance standardization and not getting stuck.
Seth Jacobs: [07:25] Uh, so that’s a good, uh, a good question. Um, so I think that the biggest thing, so, you know, we talked about like storybook, right? And that’s really a building blocks. So, um, you know, kind of injecting the word, uh, design system or design language and the conversation, um, storybook is just one of those building blocks. Um, a design language or a design system is really a collection of a lot of different things, including, um, a component library. Um, it’s also, how are those components being enraged into patterns? So you know, that we’ve got design patterns that are established, you know, what is, what is the language, you know, what is the, the, uh, the vocabulary, what is the lexicon, um, of the overall design and what are the principles of the design? You know, what is, what is the kind of shared understanding of what the design is supposed to be? Um, and that’s what a design system is really kind of, it makes up all those different things. And some people have evolved those things over time. So, uh, if you have a smaller project, um, usually a design system is not going to be something that’s really feasible because it does take a little bit of an undertaking to maintain it and to build it over time. But you can start to build it up a little bit at a time. You can say, okay, we’re going to start with a component library. Maybe we can start to establish some principles around this design, okay, let’s mark, what the patterns are. And the thing is, is the larger it gets, the more you have to maintain it, because when you start to change things, it could have cascading effects throughout it. But the benefit of the design system, which helps with the question that you had is once everybody starts to have kind of a shared understanding of how this system, um, is supposed to be put together, and we have a shared understanding of, you know, which patterns were supposed to be implemented in what cases, um, you should be able to account for a lot of the things that are coming up. Um, so if you have an instance where you’re waiting on something, and you’re not really sure where to go, there’s probably some building blocks and patterns that you’ve just already established along the way that can be put in temporarily. And then whenever it comes down to, you know, trying to minimize technical debt, it’s going to be very small. The refactoring is going to have to be very small. So you may, you may kind of work within that 80 20 rule of, Hey, based on this design system that we’ve implemented and being able to reference that and understanding what that is, and having that shared language across the entire team and, and, uh, uh, organization, the business to having all that, we’re going to be able to get ourselves 80% of the way. And then if we have, you know, an instance where we just have to get it done, you know, then you may spend, you know, 20% of that, uh, redoing it, but it’s better than someone just doing whatever they want, you know, and then it ends up just being a full redesign or something along those lines. Um, so I think introducing something like that, at least even the building blocks of it, those initial things is going to be critical to, to the teams. For sure.
Dan Neumann: [10:40] Yeah. So starting, starting small, I resonate with you and you, we talk about this thing takes care and feeding, just like, you know, if people are doing automated tests, those take care and feeding manual tests, take care and feeding these things, don’t, don’t live on their own. Some of the different agile frameworks that are out there, you know, Spotify has got their framework, Scrum’s a framework. Um, I haven’t seen too many of them kind of intentionally care for how a library or how a design language or design system might be arrived at. I, I think, you know, Spotify, when I look at the picture, it’s got the different teams and verticals, and then they draw the circle around a group of like developers from separate teams. And they say, that’s, I forget what, what term they use, but that’s a thing. Right. So that group maybe would be responsible for coming up with design recommendations or a feedback loop. How do you go about getting feedback loops from people who are working with the design patterns so that, uh, hopefully they continue to evolve?
Seth Jacobs: [11:44] Yeah. So the way that we’ve kind of approached that in the past is, um, it all depends on a couple of things, really, you know, the size of the team, um, how the teams are structured. Um, one of, one of the really important things that, uh, we found is if you can really focus your attention on having a core team best focused on those design patterns and that design library. So not even, it’s not even really like a full fledged, uh, development team, but it is a team that can be working from something like Kanban, um, having them as like a dedicated, uh, team that is, it consists of some designers and some front end developers and their, their core, um, uh, focus is really on creating that design system and flushing that out and also working kind of in harmony with each other. And they become almost like a, a little bit of a gateway, uh, for all the other teams that are developing stuff. Um, because it can be difficult to have, um, parody across teams in terms of, uh, you know, some front end developers are a little bit stronger than others, and you want to make sure that there’s consistency in that, you know, in that as well and how the code is being written and everything like this. So what we, we we’ve done in the past is, and we found it really beneficial is we’ve had a dedicated kind of core team that would actually work with the designers working through kind of a design thinking process with the business to develop some of these things out. And those, those components in that design system at all, all the assets that come with it can then be fed into all the other teams. And so they now have those things to use. Um, so that, and that’s just one approach, you know, it, it can, it can manifest in a lot of different ways. It depends on, um, you know, the type of project, uh, you know, if you have things teams dedicated to certain work streams or features or whatever it may be that, that, you know, it’s not going to be consistent across the board, as in terms of who, um, you know, who’s responding before working on some of those things. So, you know, in the past that the core team, a core core UI team is, is one that we’ve created created and that actually works out quite well. And, um, you know, we’ve created an entire process of not just them creating things and having those fed back into it, but also, um, what it means for quality assurance to quality testing. So that’s, that’s a big part of it. You know, people forget that whenever something is being looked at and, you know, the quality folks are making sure that everything looks good, it works good. It’s, it’s all living up to what it’s supposed to be, uh, that it also is consistent with how the rest of the systems working too. And there’s some of the people, you know, they, they pick up on that stuff all the time. They’re like, Hey, I use this over here. It’s not the same as how you have it over here. You know, they’ll, they’ll find that stuff even without a design system, if you have a design system to actually reference, um, and that becomes a focal point for everybody to have a shared understanding of what that means. And they can then use that as, you know, a living URL, that’s a reference point to pass, pass on and comments, or however it is that they choose to log those things.
Dan Neumann: [15:22] That was pretty cool. And I liked that. I think what you were describing was different ways to adhere to the desire, to have some standardization or even, you know, consistent approach, even if it’s not quite full on standardization, but we’re doing something that’s coherent with each other. I can see how you’re doing your thing and how we did our thing. And there’s some, some, uh, they look the same, they behave with the same, uh, and for a large program that might be a completely separate team. That’s doing that for smaller bodies of work, you know, fewer people involved, um, hopefully some faster feedback loops.
Seth Jacobs: [15:59] Yeah. I agree with that. Yeah, definitely some faster feedback loops, um, because it’s, it’s spread out less, it’s a little bit more focused. Um, but yeah, I that’s actually really well put for sure.
Dan Neumann: [16:15] So Seth, we’ve talked a little bit about, you know, a couple of examples of ways to get started or elements within a design system. You know, you talked about the storybook tool, you mentioned maybe having a component library, creating some patterns and a language or a vocabulary around these. Um, maybe just reinforce a little bit the why, why these things are valuable, where are they, where do they pay off?
Seth Jacobs: [16:42] Yeah. So I mean, you know, a lot of what we discuss is really kind of project centric, but, you know, one of the biggest payoffs is definitely for the users themselves. Um, you know, a design system helps, uh, for the, I think the largest thing it helps with is making sure that things are consistent. Um, and consistency, you know, at its core really drives into, you know, one of the really core, uh, usability principles, which is learnability, if your application is not learnable by your users, because it’s so different from one area to another, or how the, the way that you do things is so different from one area to another, um, you know, then that’s a problem. So, you know, uh, a design system and, and, and having a high, you know, a very high level of, of, uh, consistency across, um, you know, uh, how we talk about things and, you know, the not, not, not even and we talked a lot about not even really just on a component level, but how they’re all put together, the structure of the layout, all those things become embedded in how people think about your application. They get used to it, the way that they navigate it. You know, if you were to think about people navigating, you know, an application, think about, you know, in terms of like a, a upside down pyramid, right? So they’re scanning left to right or another country’s right to left. And they’re, they’re kind of, uh, descending down the visual hierarchy. They’re ingraining, all that. They’re embedding all of that, you know, into their decision-making processes and how, you know, they’re, they’re creating memory patterns of those things. So if you have a system that as you’re kind of traversing through it, and you’re navigating through it, and people are constantly getting hung up on things that aren’t consistent and, you know, it’s just not going to be learnable. And so, you know, among other things, you know, there’s, there’s other, there’s other major usability, heuristics, or principles that are key to it as well. Like, you know, making sure that you’re, you’re, you’re, uh, providing a, a system, a system level message to somebody whenever, you know, something happens, you know, is there a proper reaction for an action? Are you letting people know, you know, where they are in a system, all those things are important. And, you know, the, the different design patterns, uh, in the way you talk about things will help, uh, you know, help you through those. But the biggest benefit is definitely for, uh, the users, for sure. Um, because what’s going to end up happening is if all these things are absent, you’re not factoring that in, you’re not really looking at things through the lens of those base usability principles. Um, you know, you’re going to start to, uh, come across a situation where you’re getting feedback from the users, that all those things are an issue, and you’re gonna have to go back and fix them anyway. So, you know, you’re better trying to, you’re better off trying to start off with something like this, even if it’s at a very base building bop block level, like, you know, what we talked about that, you know, that storybook tool and there’s others that are lucky as well. Um, and if, you know, for good reference point, um, if you wanted to look at some design systems that live out there, um, you know, the biggest one that a lot of people references, uh, Google’s material design language, um, you know, they’ve written a lot of, or a lot of people in the community have written, um, various libraries, uh, out there for different technical stacks, you know, react and angular and everything. Um, and then, you know, if you’re looking for some contrasting examples, Microsoft has one called fluid, you know, Atlaseon, uh, has one as well. Um, so there’s a lot of different ones that you can look it up there. Most of them follow the same kind of theme, or they have, you know, components and patterns and kind of what their foundational items are, what their principles are. Um, they have, you know, kind of some of their branding stuff in there and let you know what the colors and fonts and all that stuff is. Um, and those things evolve over time, you know, and anytime they need to change something, something in those systems, um, sometimes it can actually have cascading effects throughout the rest of the system, but, um, you know, that’s, that’s all part of being agile is, is trying to react to things and, uh, yeah, yeah,
Dan Neumann: [21:17] Yeah. Well, and I think it’s really important that you brought the user in to, into the front. I guess I would expect nothing less as the director of the experience practice, but maybe you’ve got a little bit of a mind towards the experience of people are using these, these products. Um, but yeah, it’s, it’s not just about developer efficiency or, you know, prettier code or things like that. It’s really about creating nice experiences for the user.
Seth Jacobs: [21:46] Right.
Dan Neumann: [21:48] When, when changes do you had mentioned changes and sometimes there’s a cascading effect, are, are those usually, um, I don’t know, highly impactful, are there ways to kind of retrofit, uh, changes to design? Are there some good behaviors there?
Seth Jacobs: [22:05] Uh, I mean, they can be the thing is, is, um, and, you know, we often have to react to, you know, a business changes their mind about something, and we’re like, oh, we’ve already had, we already have all this stuff established, you know, what do we do? So it’s, it’s really, at that point, you kind of got to peel back the layers of the design and go back to the original user journeys and the goals of the user to see, you know, what kind of, what kind of potentially systemic effects that change could have, what kind of downstream effects it can have. Maybe it’s something that’s quite simple. Um, and it doesn’t affect a lot of, um, a lot of parts of the system then, you know, that’s, that’s, that’s a pretty simple fix, but, um, if it is pretty complex, then you really just gotta take it one, one slice at a time. Um, usually in that case, we try to narrow it down to the quickest and the simplest, uh, journeys that are part of that, that tree, uh, overall. And then we try to solve for those a little bit at a time, find out which ones have a little bit stronger implications than others. And just try to tackle a little bit at a time, but, you know, in terms of reacting to those business, uh, changes and having to worry about, you know, changing the design patterns, we’re, you know, we’re not, we’re not concerned about changing design patterns. It’s all really about, you know, how much value can we bring to the business or the user, um, but tackling it and making sure that we’re, we’re looking at things, not just from what we’re seeing on the application, but from the, the user’s journey. That’s, uh, that’s a little bit better approach, um, because it takes away the visuals and then it starts to really focus on, are we still achieving the goal that they’re setting off to achieve, um, and, and know that works out quite well.
Dan Neumann: [24:00] Totally makes sense. And I liked that you were advocating for, um, you know, looking for the most impactful places or the things that have to be done first, the best bang for your buck as you continue to evolve, uh, a design pattern there. So, Seth, thank you for taking some time today, talking about, uh, technical excellence and especially from a design language or a design system pattern and helping people wrap their brains around how these systems and patterns are helpful, maybe how to get them started, how to use them, and then some of the implications of evolving them over time. So really appreciate you taking that time.
Seth Jacobs: [24:39] That was great topic.
Dan Neumann: [24:40] We ask our guests typically at the end, what’s on their continuous learning journey or has some kind of interested. And so I’m curious, what’s on Seth’s, uh, curiosity journey.
Seth Jacobs: [24:51] Sure. Um, yeah, so, you know, human sciences has been something that’s been a, a pretty deep passion of mine. I’m always looking to kind of broaden my, my knowledge about that learning, you know, about humans and the, uh, I guess the, in a different way than how a lot of people really look at things in the, in the UX world where it’s, it’s mostly about, you know, kind of what we talked about. It’s mostly about design patterns and user journeys and all that stuff. Um, so, you know, I did pick up a book, uh, called thinking fast and slow by Daniel Connolly. And, um, you know, he really kind of talks about, you know, the decision making processes that, um, people go through both consciously and unconsciously. Things we do automatically things that, you know, we do intuitively and, you know, that’s been a, it’s been a really good read and it’s been stuff, stuff that, you know, we’ve been looking on, we, or looking at introducing it to the practice a little bit more. So, you know, that’s been kind of what I’ve been looking at it. And, uh, yeah, I recommend it to anybody that’s out there.
Dan Neumann: [25:57] That’s pretty cool. Yeah. How decisions get made, which ones get made almost automatically and how to slow down decision-making where appropriate. Totally interesting topic for sure. Well, thanks a bunch for sharing again, Seth. I really appreciate it.
Seth Jacobs: [26:11] Awesome.
Outro: [26:13] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.