When I first discovered Design, I soon understood that what made me want to join the industry was the never-ending quest for optimization. As far as I remember, this has always been a goal in both my personal and professional life. My cross-cultural management Master’s Degree was based on the principle to improve the way people from diverse backgrounds and places come together as a functioning unity. A few years back, when I was a Knowledge and Project manager at BNP Paribas Cardif, the idea was to support the company’s digital transition by optimizing the way in-house teams worked together. So later on when I shifted towards Product Design at Ironhack, needless to say, that Design Systems immediately aroused my keenest interest both by their inner nature and the prospects they opened up. Since then I am constantly finding ways to work towards this utopia of an automatized structure that allows Designers to solely focus on what matters the most: the user.
Having this in mind, I connected with InVision Consulting Director Nick Hahn to have his take on the topic of Design Systems and get inspired by his feedback.
Nick and his team at InVision help companies get the most out of their Product process and advise them according to their specific level of Design Maturity. Thanks to his years at IBM and now at InVision, his experience gave him tips on do’s and dont’s which he shared with me over Zoom.
It’s not a secret anymore, Design has been owning its voice in the strategic discussions over the last years. To Nick Hahn who has been in the field for nearly two decades now, not only did we come a great way already, but Design might be on the verge of reaching a whole new level in the years to come.
If you have no idea what a Design System* is, Nick found the perfect analogy all the while paying a tribute to Ford’s assembly line that revolutionized industry and craft management:
“When the assembly line was created, they had to create clear systems and guidelines for crafting those cars (…) That’s basically the point that we’re at in the digital product space: we’re moving from it being hand-built small crafts, teams of craftspeople, to developing and shipping product at a much larger scale.”
What does it have to do with Design Systems? Well, they help you build faster, better, and greater products by industrializing your process thus avoiding handcraft from scratch every single time.
* Be warned, I might refer to Design System as DS down below.
Like DesignOps*, you’re probably already working towards this goal without knowing you are. As reminds Nick — asset libraries, style guides, design guidelines, are the premises of what constitutes your Design System. So getting started is as simple as doing “an audit to go through your company’s existing properties”, says InVision Design System Consulting’s Director.
To learn about DesignOps, check my article on the matter!
Another important tip given by Hahn is to focus more on experiences than assets during the audit. Meaning that instead of wanting to get consistent on, let’s say, the search bars throughout your products, audit your sign-in flow, and check how many ways there are to complete this user task.
Unlike auditing, when entering the creation phase you want to start small and go incrementally. In the same way, it would indeed seem very odd to aim at building an entire car all at once — starting with each small piece and assembling little by little would then be the way to go.
“Many teams get stuck in thinking they have to build every component that they can imagine, document it to death, and then try to get everyone to use it. And you’ve seen many teams fail at delivering and creating design systems going that direction. So I’d say the place to start is just create one component and get all the teams that you can think of to use that single component.”
Implementing a DS little by little should not prevent you from seeing the big picture though. For instance, thinking about your components as tokens will help you go the extra mile when building master components and will improve the time-to-code in the end. As Nick explained, Design Tokens are becoming “the industry standard” particularly because the handoff gap between Design and Code still can be expensively wide.
We could tend to assume that companies that get intentional about building a Design System already have a rather high-level Design maturity and a good Product Culture. The truth appears to be more complex than that. Indeed, getting started on a Design System might translate a company’s pain point that might get fixed by a DS. Or it could be just a way to keep up with the trend. Either way, sooner or later this organizational project — because yes it’s more about automatization than design — will point out your strengths and weaknesses as a company regarding your end-to-end production management.
“I see teams all the time, they buy a design system manager, and they think ‘if I buy this tool, it will solve my design problems (…) magically, we’re going to have the design system (…) it’s going to solve all the problems.’ But what it really does is it ends up shining a light on the maturity level of that design and product organization. It kind of like, cracks it open, and and gets everyone to look at it and go ‘Oh, crap, we have a lot more work we need to do to make a design system work”
But we should pursue this “Oh crap” moment says Nick, because it’s when you start asking yourself the right questions on cross-team collaboration especially between product teams and developers.
To push companies to realize where they are at but also and above all how they can evolve from there, InVision came up with a Design Maturity Assessment (DMA) that they tested on thousands of companies.
“It’s about looking at a companies from every angle and assessing [their] level of maturity. It gives themselves as a company an understanding of like ‘Oh we thought we were doing things kind of advanced but we’re really behind compared to the rest of the industry, what can we do to go to the next level?’
Getting the tools such as InVision DSM is one part of the process, but making it the company’s single source of truth is the ultimate goal. When you eventually succeed at gathering the focus onto one place where the work gets done and iterative versions are created, that’s where you reach a whole other level that will propel you to higher quality and efficient delivery level.
To get there, you will need to stop looking for game-changer tools unless you are sure of what you want to do with them. Companies can buy the biggest and most expensive delivery management tool and still not get it right. Remember, the magic recipe lies in the why.
When built as such, Design Systems are also meant to prepare your products to scale in the most efficient way possible. But how do we deal with the DS’s scalability itself?
I asked Nick Hahn this question as it’s a daily issue for me as a Product Designer: how do we keep consistent while constantly changing our Design System because all we do all day is iterating?
The key is knowing that a Design System is not just a checklist you have to go through nor a big task you have to overcome once and then it’s done. It’s going to change, you’re going to make it evolve, and maybe, you’ll switch directions just when you’ll feel you’re almost there. Should you have been aware of those possibilities first, you’ll be alright.
Scalability is an issue on the Product Team of course, but it’s sure is for Developers too. Especially in teams where the Design Culture has not spread yet. So I asked Hahn about convincing teams about a Design System’s added value when they have always worked with ready-to-use libraries like Bootstrap and made go with it.
“I hear all the time from engineers and developers: ‘Designers just keep changing everything, I just don’t understand what the heck this changes are for!’. It’s just a very constant, consistent theme. And the reason for that, I found is that: one, (…) the frustration and impact of the development side is much greater than what the designer understands. And second, we’re designing systems [so] we should codify [variables] and put that into the system. And now, as a designer instead of making changes, I can think about the real users pain, and be thinking about the next level of design priorities, which is, what my users need to do? What can’t they get done? And how do we get alignment with my business around those real user pains and create unique solutions for that? It helps elevate us from being the bricklayers of building to the architects, right?”
On proving Design and Product overall’s value, we shared some similar experiences with Hahn. Even if we keep saying Design has now a seat at the table and is more and more in the loop, there are still major misunderstandings on what our job is.
“I think there’s a mis interpretation with design, with companies that are primarily engineering-led, (…) they see design as a whole other phase that needs to get added before a project starts. Because they think starts mean, ‘I’m coding something.’And there, it just takes repetition and (…) time to show that when we start making some of the decisions earlier, before we put the expensive cost of coding in, we can avoid a lot of mistakes. [Or best] not avoid mistakes, [but] we can make the mistakes earlier when it’s (…) less expensive to fix.”
I love ending my interviews with a little forecast session. So naturally, I asked Nick how he would imagine our Industry to look like in 5–10 years from now and I find his prediction to be super interesting:
“The designer’s job is gonna change pretty dramatically. (…) As we evolved really over the years, the visual designer has less and less to do: if the visual design is baked into the Design System — what are they doing? We’re working in lower-fidelity because we’re doing quicker iterations. So if you take that to the next level — (…) the majority of your company’s primary experiences (filtering, log in, validation, check out) are patterns that are used everywhere. You don’t need to design those anymore, it can be iterated on, but we no longer need to design it.
So now what does the designer do? Just sit around and not be designer? No. We get a chance now to think about the workflow of how users go to A, to B, to C. We spent our time thinking what jobs to be done need to be done and testing iterations of those. So I imagine a world of instead of our design tools being primarily screen layout, [something] where a designer (…) moves box around that are workflow elements. Now imagine if that’s tied to a Design System and a coded library that automatically produces a coded prototype. It doesn’t have to be as complex as production level of code, but if (…) I could then send [it] to a user who goes through it (…). I think it moves our jobs away from being pixel pushers to more of logic organizers and creating those flows while interacting with customers.”
<hr><p>Great Design automation and collaboration tips with Nick Hahn was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>