10 practical tips for getting your client’s Design System off to a great start
As a designer in the agency & consulting world, I work with companies that have a wide range of in-house design maturity. Some have zero internal design presence, while other have seasoned designers and developers. Each situation provides unique learning opportunities. Much of my recent work has centered on helping clients build their first design system, one of which was American Airlines’ design system for a collection of enterprise applications.
This post focuses on what I’ve come to recognize as important first steps to get your team moving in the right direction, and how to be a better leader as an embedded designer in a client team. So, for a moment let’s put aside the nitty gritty details of design systems like typography scales or 8pt grids and talk about how to approach the somewhat of overwhelming task of even starting!
If you’re unfamiliar with the general concept of a design system, then I’ll quickly introduce you. Otherwise, skip ahead.
A certain thing happens to practically every organization that builds a family of digital products for customers, partners, or their employees. If the original product has some success, or investment to continue beyond a first release, the original excitement of “We’re really doing this aren’t we, Harry?!” shifts into a scene of loosely controlled chaos as the team(s) change people and build more.
A number of pain points can emerge. These are just a few:
Design systems address these problems. A design system is essentially a centralized, standardized, and reusable collection of user interface components (buttons, inputs, menus, etc.) visual styles, usage guidelines, and code that is all aligned. It is kept up to date with new user and product needs, and is immediately accessible to the team, typically on a website. The result is something is meant to help everyone on the team be more efficient, and the products consistent and optimized.
Want to know more? Here’s a good place to start…
Every team sits somewhere on a continuum of maturity in terms of their design and engineering practices. Some teams can be running smoother than a Swiss train schedule despite only having existed for a number of months, while others may have been together for years and are hamstrung in a number of key areas.
Understanding where the team you’re working with is at will help you identify where you can add the most value, and also foreshadow where you may encounter challenges.
Maturity model adapted from Inzovu and UX Matters.
There are two main areas you can start to look at to get clues about the maturity of their practice: a) Craft, and b) Operations.
a) Craft has to do with pure design capability of the team members and the activities they are empowered to do. This includes a lot, from the research and data gathering methods currently in use, to the presence of divergent and convergent design thinking, to the skill sets required to create a beautiful interface that solves a real problem with a high degree of usability — and more!
For example, if you’re working with designers accustomed to defining all the interaction states for a component then you’ll likely avoid time spent educating them about those different states and making that a habitual part of their process. If not, then something that fundamental could take weeks.
When it comes to research, many companies don’t have meaningful ways they listen to their users and aren’t comfortable with the close-up nature of human-centered design methodologies. The path getting them there can be long and littered with political barricades. After all, the behavior that gets employees rewarded in many traditional business settings can be at odds with the open-ended, more-questions-than-immediate-answers qualities of design.
You can get a rough feel for Craft by interacting with some of their products. I recommend supplementing that with a series of 1:1s with key people on the team. You’ll get to hear their more candid thoughts which will help you triangulate where the true strengths and opportunities for improvement exist in their practice. It’s important to remember that this shouldn’t be a secretive endeavor, and isn’t intended to find “weak links” or be exclusionary. Do it in a way that is transparent, and respectful to the people and setting you’re in.
b) Operations — Or as it pertains to Design, ‘DesignOps’, as many are calling it. It is the surrounding structure that supports the Craft, and can be greatly influential in propelling or limiting the team’s ability. Forces such as recruiting/hiring practices, how designers/devs are positioned within the org chart or on projects, having a culture of feedback and critique, governance & workflows, tooling, and the KPIs driving decision making are just some of the high level areas that comprise DesignOps. Those 1:1s will also shed light on the inner workings from the operational side.
Building a design system with your client doesn’t mean every factor within the craft and operational areas is going to evolve in your time on the job. However, all that is to say with certainty that the Design System you build will be shaped by them. Probing a bit and making observations about various aspects of their practice early on will help you navigate your road ahead.
This is a common step listed you’ll read about elsewhere, but it belongs here too. Invest time upfront to perform a UI inventory of the relevant pre-existing components, applications, and interaction patterns, so that everyone is on the same page about what’s in use.
I recommend starting this activity by actually printing out designs on paper and taping them up in a meeting room wall where everyone can freely look between them, which should spark a lot of good conversation.
Inconsistencies, scalability issues, and usability problems should become more evident from the start, helping your team prioritize your backlog. Just as importantly, doing so can help reduce friction and prevent the team from hanging onto an inferior element just because it has the precedent of being already in use, or due to emotional attachments. It also helps avoid the scenario of building something from scratch only to find out a version of it existed already that is good enough! Just as importantly, it will begin to establish a shared language across the team as to what elements should be called.
In addition to setting the goals of the design system itself, take time at the start to write out some high-level principles. They should voice the intrinsic product qualities you wish to exude through the design system. Having a set of principles to look back on will come in very handy during the numerous moments you’ll be judging the merit of two design alternatives, and all things seem equal at first pass.
An example: My team was building a design system where the end users of the applications were aviation mechanics. Their current tools and day-to-day communication involved a ton of technical industry jargon and abbreviations. Based on the finding that it takes a new employee a year to achieve basic competency with tools we were replacing, one of our objectives was to shorten job training time. Therefore, we drafted the principle:
“Use everyday language whenever possible”.
Following this principle resulted in a series of guidelines that demonstrated how to write instructions, form questions, and other content throughout the products in a fashion that worked to help new employees learn key concepts or phrases more easily, while avoiding being overly wordy.
It’s easy to rush into producing components on day one. In fact, I can almost guarantee there will be some pressure to do so. The trap here is that if you don’t step back and ask, “how should the different pieces of our system look and behave in a way that reflect our principles, user goals, brand, and overall mission?”, then you may end up with a collection of components and patterns that aren’t truly unified. The result can feel disjointed or underwhelming. If you have multiple visual designers churning out components, it’s even more likely for this to happen.
To avoid that pitfall:
Or you might say, “ship early and often”.
While the value in building a Design System might be a no-brainer to you and I, you should keep in mind that it can still be a foggy concept to some stakeholders or product owners. Someone allocated part of their budget to the project, and others are likely experiencing some pain point in their world that the Design System promises to solve. Some can even be resistant to it entirely as they fear it will impact their product or timeline negatively.
The counterpoint to all the level-setting “do this first” steps I’ve made above is that those individuals want to see hard evidence of progress in their actual products, and sooner than you think.
For that reason, it’s best to identify a few components that are causing headaches among users or stakeholders and tackle them quickly. If there are no immediate headaches, pick some low hanging fruit. Make a habit of regular smaller releases rather than big reveals, and work to get the components officially integrated into the products as soon as you can. If you don’t, the pressure on your already high-profile project can intensify as folks may begin to question the value of the initiative. Conversely, if you ship a component that removes that thorn in their side within the first couple weeks they’ll start skipping through the hallways singing about your great work.
The team must identify the necessary processes, people, and responsibilities required to maintain and iterate on the Design System after the first big push. Otherwise, it just becomes another artifact that no one owns, or worse, uses.
The key from a people-standpoint is having open and honest conversation about who will own the future maintenance and development of the design system, what their current job entails, and how their priorities will be managed. Short of creating an entirely separate “Design System Team”, the reality is that some people are going to have more put on their plate. If a particular person seems to be constantly behind on their work, then they aren’t a good candidate to review and approve code in a timely manner.
Map out an intended workflow with the team from the moment a need for change is identified through to when that change goes live, and after.
Ask questions like:
Being brutally realistic about these types of questions will help shape a governance model that can actually be held up. In the meanwhile, the team can identify long term needs around people and processes that they can put in their road map.
If you’re brought on to support an in-house design team because they’re too occupied to push the pixels and write the code for their own Design System, then there is a risk that some members of the team will be detached at moments throughout the journey. This is unfortunate not only because they’re the ones who will be using and must understand it, but also because you can miss out on valuable feedback.
To combat this, consider getting people to commit to micro-roles. Micro-roles can include performing a bit of code QA, being brand-cop, or reviewing the accessibility of a component, among others. This tactic will achieve two things:
If you want to have a design system that describes in words to the reader the principles, guidelines, “do’s and dont’s”, and other reasonings behind the system, then you can depend on spending more time writing and editing than you anticipated.
It’s best to designate someone who’s good at writing as the official copywriter, and make it a considerable part of their role. Having someone tasked with copywriting should help in maintaining a consistent and coherent voice from one area of the design system to the next.
It seems like every time you hear someone talking about their awesome design system, it appears as though they built every component from scratch. While that may be the case for larger organizations like Google, Shopify, or Salesforce, I’m not sure how frequently that is the case for others. Doing so can be a very time and money intensive endeavor that not every org is prepared to undertake.
If you have a more abbreviated timeline to get things moving, then consider using an existing UI Component Library. There are lots of robust and technically sound options out there that can be edited to meet design requirements or philosophies. This can be especially good for a team building their first design system as the library developers have probably accounted for more technical considerations than you have time to address.
Of course, there are potential downsides to this approach, such as the scope of the library, support, and licensing fees. Still, many teams may find this most economical and fruitful route. Here are a couple that come to mind.
(I am not being compensated for including these links)
If you want to hitch your wagon to the Material Design language, then there’s:
Alright, I admit this one is more nitty gritty than I said I would get, but it bit me so I figured why not?
If your team happens to be using Sketch for screen design and you’re keeping a symbols library that acts as a static representation of the coded components (most do), then to keep organized you’ll likely be using slashes in the names of your symbols to enforce organization within the library menu. Doing this is especially helpful to separate top level master symbols from nested symbols, if you chose to do so (highly recommended for ease of use!).
At the time of this writing, there isn’t a really efficient way to rename components or layers quickly without using a plugin like Sketch Symbols Manager or Rename It. You have to do it one by one manually, and if you keep putting it could be painful later on.
So, trying to align on the symbol naming conventions and hierarchy ahead of time will avoid that and also help in establishing a shared language across the team. Hey, maybe this one has a bigger purpose after all.
Thanks for reading, and to my teammate, Eva Forrest, for helping me put this list together! I hope it was helpful in some way. Please leave a comment and let me know about your experiences, or what you would add.
10 practical tips for getting your client’s Design System off to a great start
Research & References of 10 practical tips for getting your client’s Design System off to a great start|A&C Accounting And Tax Services
Source
0 Comments