Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Quick Tips On Design Systems: Sell The Output, Not The Workflow

So how do you sell a design system to the client? How do you establish a shared commitment within the company to put a pattern library on the roadmap? As designers and developers, we often know and see the benefits of an overarching system that radiates consistency throughout the different experiences of a company. But sometimes it’s seen as a very unpredictable investment, and the value isn’t necessarily visible right away.

In his article on Selling Design Systems1, Dan Mall suggests to illustrate how fractured an organization is by printing out its different presences online and putting them on a large board as an example of all the wasted money and effort that goes into making sites from scratch, one-by-one, needlessly reinventing the wheel every time.

You can illustrate how fractured an organization is by printing out its different presences online and putting them on a large board. Credit: Dan Mall2
You can illustrate how fractured an organization is by printing out its different presences online and putting them on a large board. (Image credit3)

Making inconsistency visible is helpful for revealing and highlighting the underlying issues, but how do we drive the point of introducing consistency with a modular design system that’s built out of modules, not pages4? What I learned from my experience is that trying to focus on the workflow or the process is never as helpful as focusing on tangible benefits that the client will get as a result.

Further Reading on SmashingMag: Link

Clients usually don’t want to hear about atomic design and modular design and standalone patterns, but they love seeing the output, be it working prototypes or a page with all components on them.

Project Hubs8
One way to display the output better is by using a project hub109. This one was open sourced by Brad Frost.

One way to display the output better is by using a project hub109 — one central place with all the important assets all collected in one place, sorted chronologically, and always up to date. As a result, the client can come to the site at any time and see the progress right away. You could even add the contenteditable attribute11 to make text editable in your responsive prototype, so if a stakeholder wants to adjust the text, she can do it in every browser12, and then resize the window to see how it works on narrow screens, too.

Whenever we work with companies, we never try to sell atomic design, and we rarely sell design systems. Instead, we’re selling the ability to quickly see output with a new approach that — accidentally (or not) — includes modular design methodology. We’re “selling” project hubs and quick turnarounds, and often establishing a design system is a major part of the conversation with designers and front-end developers, but not what drives the conversation forward with clients.

Strategies For Putting A Design System On The Roadmap Link

Sometimes it’s not about selling the consistency to clients at all though, but rather establishing it as a clear priority within the entire team, from marketing to content managers to support team. And focusing on output can be helpful here, too; especially since the output can be slightly more than just a set of working prototypes. In his recent talk at the Clarity conference (wonderfully orchestrated by Jina Bolton13), Nathan Curtis14 suggested a few15 tactics16 that, in his experience, often ensure that design systems take root at an organization.

In his experience, to ensure that a design system is successful within a team, it’s absolutely critical for it to be efficient, i.e. help all parties involved to save time and get to results, faster. But how do you convince a client of the value of something that doesn’t exist yet? Well, by creating this value. What if additionally to a board with current, inconsistent experiences, put up another board displaying what consistency could potentially look like? What if you redesign the basic shell of the page (perhaps just a header and a few critical buttons) to work across all experiences, print them out, too, and put the two boards against each other? Before you know it, designers and developers might be excited to normalize even more of the UI components.

Measure Design and Provide Actionable Data Link

Obviously, visual design is extremely subjective, so bringing in metrics and data — e.g. on conversion rates — helps convey an argument more efficiently than anything else ever could.

Define a user journey that involves different experiences (e.g. a user landing on a landing page, then browsing the shop, then checking out, then checking the state of delivery in the native app on their phone), record the interview and show it to stakeholders — or, even better, invite them to observe the session as it happens. Then conduct another session with users using a quick prototype with the “consistent” navigation, compare results, and outline them clearly. If results are way below your expectations, it’s probably better to keep iterating on the design until you have something promising to show.

Focus on Pain Points Link

If this strategy doesn’t work or isn’t applicable, try to focus on the pain points within the organization. The existence of visually different experiences is often an indicator of different systems — often quite dated systems — used behind the scenes. Of course, these systems do have to be connected somehow, even if it’s just for sales monitoring or quality assurance.

Alternatively, we sometimes spend some time reviewing the backlog and technical/design debt dusting up in the customer support department: usually a quick coffee break with seasoned customer support employees is extremely valuable for uncovering common pain points that hurt conversion or user engagement. You could try to target the pain points specifically and figure out a way of resolving some of the issues with a consistent design system. Again, focus primarily on the output, not the workflow.

Approach Less Visible Levels Of Consistency First Link

However, neither stakeholders nor loyal users like major, disruptive changes, and “big-bang”-redesigns — nevermind how impeccably consistent they might be — often bring more harm than good17 to customers who’ve been using the website for years. So what if instead of suggesting a major overhaul, we look into ways of defining and introducing various levels of consistency? These levels could range from less visible (padding, typographic scale) to more visible ones (buttons, icons, layout), and, frankly, you don’t even have to mention the “visible” levels at the very start of the project.

Short Design Sprints With User Interviews Link

That first level of consistency is often not that difficult to achieve across a set of critical pages. However, depending on the complexity of the project, it might seem daunting to embark on the journey of that scale. In the end, it’s all about being efficient, and there is no better way to get to results faster than with design sprints18: a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

Design Sprints19
Design sprints introduce a concept for answering critical business questions through design, prototyping, and testing ideas with customers. Image credit.20

Whenever we’re brought in companies to solve problems, be it streamlining UX or front-end optimization, we don’t have a lot of time to produce meaningful results. Depending on the context, we tend to set up user interviews early on, and often the third day includes 4 user interviews scheduled within a short period of time between each other.

The principle is easy: eliminate distractions and create constraints to be creative in-between user interviews. Ideally, we run a 15-min interview at 1PM, and then spend 1:15h improving the design — based on our gut and the user session, because we have another 15-min user interview scheduled at 2:30PM. After the second interview, we have exactly 1:15h to come up with the next iteration because we have another interview scheduled at 3PM. It means that nobody in the team can afford spending more than a few minutes deciding on what’s getting done within the next micro-sprint. Because you rely on getting things done before the user testing, the entire team is dedicated to roll out results on time.

Obviously, you might need to use a timer to ensure that you don’t mess up with the schedule. Also, while users are already here, you might run a few other tests while the team is working on the next iteration.

Radiate Consistency From Web Apps Link

But how do you strategically choose the components to start a sprint with? Well, if a company provides a variety of experiences across different systems, ranging from content-driven websites (e.g. presenting a hotel) to task-driven web apps (e.g. booking rooms, account management) to native apps (e.g. booking rooms, account management), what’s the best way to start bringing consistency to the entire set of “properties”? According to Nathan Curtis, it’s more efficient to “radiate influence from web apps” as they are often the most trackable, transactional, utilitarian assets21 and prove to be good candidates for leading the design system creation. Or, to rephrase, “radiate influence for marketing sites and native apps from core product”.

Radiate Consistency From Web Apps22
In his talk at Clarity, Nathan Curits was suggesting to radiate consistency from web apps instead of websites or native apps. Image credit.23

It actually does make sense. Web apps have more in common with both native apps and the website than, let’s say, a content-driven marketing website has with the feature-driven native app. By targeting the components within the critical core, or essence, of your website, you automatically target modules that will be repeated throughout the entire range of experiences, “radiating” throughout all “properties”. Could be worth trying out.

PDF Worksheet For Design Systems Link

To get started, we need to build a shared commitment to designing and building a design system first. And to get there, we could define parts, products and people24 first, just by completing a two-page PDF worksheet2825 (or INDD26) collaboratively. The goal is to collect data that will inform system strategy and priorities. Obviously, the worksheet would need to be applied in a workshop.

Two-page PDF worksheet27
A two-page PDF worksheet2825 for establishing a design system in the team.

Component Cut Up Workshop Link

Now, to achieve that goal, Nathan suggests to get as many people involved in the project as possible in the same room, and run a Component Cut Up Workshop29 — print out the screens, ask everybody to identify and cut the components, then group and name the components, thus establishing a shared vocabulary. Alla Kholmatova30, an interaction designer at FutureLearn, encourages to involve both designers and front-end developers in the workshop31.

Component cut up workshop32
Cutting and grouping components in a component cut up workshop, by Alla Kholmatova. Image source.3633

Beyond cutting and naming the components, Alla suggests to arrange components into abstract buckets34 to indicate priorities and functionality, ranging from “helpers” (components that can’t exist on their own, e.g. the “reply” button) to “bridges” (components which act as connectors, e.g. breadcrumbs or pagination) to “standalones” (components that can be viewed as self-contained units, e.g. a “hero”-box).

35
Grouping and naming components workshop, by Alla Kholmatova. Image source.3633

You could even create a Slack channel to drop a component and ask the entire team to name it and assign it to a pre-existing family of components. You could even go as far as involving users into cutting, organizing and naming components, even if it’s as informal as a quick session in the nearest Starbucks.

Summary Link

But is it actually worth it? Does every website need a design system? Do we absolutely need to follow our obsession with consistent, predictable design patterns that beautifully keep repeating across different UX touchpoints? I don’t know.

What I do know though is that in many situations modular responsive approach can be extremely beneficial for companies that a) share many similar components across various experiences, and b) struggle with fragmentation of mobile devices and maintenance issues. This is where design systems shine.

Frankly, I’m yet to encounter a client that would be genuinely, passionately excited about the atomic design methodology or a module naming workshop. However, everyone does get passionately excited about time-saving features and better, faster output that they can engage with. With project hubs, actionable data, addressed pain points and non-disruptive iterations. Next time you encounter somebody not seeing the benefits of a modular approach, try to convince them of the tangible benefits and the output, not the workflow you’re using. You’re much more likely to succeed this way.

(vf)

Footnotes Link

  1. 1 http://danielmall.com/articles/selling-design-systems/
  2. 2 http://danielmall.com/articles/selling-design-systems/
  3. 3 http://danielmall.com/articles/selling-design-systems/
  4. 4 http://daverupert.com/2013/04/responsive-deliverables/
  5. 5 https://www.smashingmagazine.com/2016/12/how-creating-a-design-language-can-streamline-your-ux-design-process/
  6. 6 https://www.smashingmagazine.com/2016/02/efficient-responsive-design-process/
  7. 7 https://www.smashingmagazine.com/atomic-design-workflow/
  8. 8 https://24ways.org/2013/project-hubs/
  9. 9 https://github.com/bradfrost/project-hub
  10. 10 https://github.com/bradfrost/project-hub
  11. 11 http://html5doctor.com/the-contenteditable-attribute/
  12. 12 http://caniuse.com/#feat=contenteditable
  13. 13 https://twitter.com/jina
  14. 14 https://twitter.com/nathanacurtis
  15. 15 http://bradfrost.com/blog/post/clarity-conferencebeyond-the-toolkit-spreading-a-system-across-people-products/
  16. 16 https://codepen.io/chriscoyier/post/clarity-2016-wrapup
  17. 17 https://articles.uie.com/radical_redesign/
  18. 18 http://www.gv.com/sprint/
  19. 19 http://www.gv.com/sprint/
  20. 20 http://www.gv.com/sprint/
  21. 21 http://bradfrost.com/blog/post/clarity-conferencebeyond-the-toolkit-spreading-a-system-across-people-products/
  22. 22 http://bradfrost.com/blog/post/clarity-conferencebeyond-the-toolkit-spreading-a-system-across-people-products/
  23. 23 https://twitter.com/sophshepherd/status/715611781733834752
  24. 24 https://medium.com/eightshapes-llc/picking-parts-products-people-a06721e81742
  25. 25 http://eightshapes.com/images/documents/PickingParts-Products-People.pdf
  26. 26 http://eightshapes.com/images/documents/PickingParts-Products-People.indd
  27. 27 https://medium.com/eightshapes-llc/picking-parts-products-people-a06721e81742
  28. 28 http://eightshapes.com/images/documents/PickingParts-Products-People.pdf
  29. 29 https://medium.com/eightshapes-llc/the-component-cut-up-workshop-1378ae110517
  30. 30 https://twitter.com/craftui
  31. 31 https://about.futurelearn.com/blog/atomic-design-molecules-organisms/
  32. 32 https://speakerdeck.com/craftui/modular-design-at-work
  33. 33 https://speakerdeck.com/craftui/modular-design-at-work
  34. 34 https://speakerdeck.com/craftui/modular-design-at-work
  35. 35 https://speakerdeck.com/craftui/modular-design-at-work
  36. 36 https://speakerdeck.com/craftui/modular-design-at-work

↑ Back to top Tweet itShare on Facebook

Vitaly Friedman loves beautiful content and doesn’t like to give in easily. Vitaly is writer, speaker, author and editor-in-chief of Smashing Magazine. He runs front-end/UX workshops, webinars and loves solving complex UX, front-end and performance problems in large companies. Get in touch.

  1. 1

    Absolutely agree:
    Why to sell design systems? As designers (and digital agencies) we are selling the right solution and the realisation of clients goals. By what means and how will we achieve client’s business goals – it is not an object of sale, it is a way of bringing goals to life.

    My thoughts (based only on my own experience, I’m not disputing the author’s opinion)

    1) There is no doubts – not every website needs a design system. I would rather say, that website doesn’t need to have a system. Providing simple guidelines will be enough here. However, design systems (and very structured guidelines to them) are “must-have” for platform solutions and, of course, brands. The bad situation is that companies still don’t understand the purpose of having a system: they treat it like a set of non-breakable rules and even as a limited area for their activity (such limits make their life easier). While the truth is that guidelines are a way of handling the knowledge and the idea behind the product or brand to others – be they company’s employees and board members or another design agency, that is hired for the product/brand maintenance.

    2) But yes, we need design systems – to break the patterns. When we have a perfect consistency within everything – experience, voice, visual – we are in danger of becoming “invisible” as time goes by. Here patterns come to the point: the brand breaks it’s own pattern and stands out. The secret sauce is the art of breaking patterns in a right way, but that’s another story ;)

    3) As about selling the workflow.
    I totally agree that we don’t sell the method how-we-will-do-it, but also have noticed that selling benefits doesn’t work everywhere. What works always – is selling the goals achievement. Yes, a little more work here, because every client has their own goals, while (usually) benefits of using a product are common for a particular category of customers.
    And besides selling the goals achievement, we SHOULD explain the workflow and introduce all stakeholders (who will accept designs further) to how we work. Because for them, it is not how WE WORK, but it is how THEIR goals will be turned into the reality. It ensures them that everything will go smoothly. Just one more reason “for” to hire our agency.

    4) I think the author of mentioned at the beginning article used the word “workflow” in a bit wrong meaning. Workflow – is how we work, what the project stages and sprints are (“Sprint” book is awesome, btw), what, how and when we will deliver, who is engaged, etc. Atomic design – is an approach to designing systems, not a workflow (please, correct me, if I’m wrong here).
    I think that we should explain our approach to client, only if they ask for such explanation. Or mention it on the presentation of the first concepts (or at the early demos). But in this case we don’t need to sell it – client has already hired us.

    3
    • 2

      And special thanks for The Component Cut-up workshop! Will definitely try it with my team.

      1

↑ Back to top