Designing design systems

On the second day of Enterprise UX 2016, the session was about Designing Design Systems, facilitated by Jack Moffett.

Jack is a graduate of Carnegie Mellon, and works for a Boeing subsidiary now.  He is also the author of a recent book about the collaboration between engineering and design.  The topic of design systems has emerged in conversations throughout the conference, so he is looking forward to unveiling for us today.

Design Systems: From Project Done to Product Sustained

Nathan Curtis is the founder of eightshapes in DC.  He is a foremost authority on design systems – speaking at conferences, running workshops, and of course advising customers.  He wrote a book on it in 2009. 

I had the opporutnity to meet Nathan in the shuttle on the first day of EUX16.  We got to talking about his presentation, and when I said we were building a design system in my current team, he leaned in and started peppering me with all kinds of really good questions.  Here is a guy that is absolutely passionate about what he does, and super articulate.   Even though this is work we are doing already, in retrospect I think his enthusiasm and compelling delivery made this one of my favorite presentations at the conference.

Nathan has been consulting with big companies like Cisco, Yahoo, etc., and through that work he learned about tooling a design system and how to approach it. He shared one of his own customer stories, and then launched into some specific feedback about Google Material Design, to help explain what a challenge it is to do this work.   Nathan said that Google does a good job making their solutions visually cohesive, and there are good practices about information architecture and iconography.  But you can see the divergences if you put those applications – including Chrome – next to each other.  So that said, what does this teach us about how you communicate standards?  What is the primary red among the choices of red?  When you ‘tune the dials of those design choices’ you’re making, what happens to the cohesion you’re seeking?

As a starting point, he showed us a simple example in which we looked at Typography, Color, and Iconography.  There are so many other considerations too, like (white) Space. And even Style (yes, content style).  A card – or a series of adjacent cards – enables you to show all the elements together.   But even using the same design system, you can create things that do not look the same:

This is fine three weeks in, but not where you want to be eighteen months in!  As part of his methodology, he has an inventory of parts that he reviews with his project team.  He has teams cut up the elements, regroup, and prioritize them.  Once the group knows what elements are needed, they can create concepts or sample designs. The goal here is not to micromanage the design work – you don’t want to design everyone else’s product – but you want to invoke the system so you can talk about ‘how to get from here to there’.

In addition to creating the system itself, the governance piece also needs to be planned.  How are we going to get this system to run, to operate, to be self-sustaining?  Hopefully you read the design spec or a code library .  And when the style guide launches there is lots of love … but after that it’s hard.  What is the mission?  Real success is when what you’re doing positively affects the customer experience.  It’s not just about products, but about the people that are impacted.  So a project like this can have a variety of goals:

When it comes to implementation, the challenge is to choose the flagship products that will commit to you, too.  How do you choose the right 3-5 products, the ones that will launch with the system that you will create?  Avoid the submarines!  How are you going to have those conversations, and establish a realistic launch date? At Cisco, the engagement he lead focused on Support, because it was clear that was where customers spend their time.  An interesting insight is that he doesn’t typically go after the Home page because its often highly political and unstable.  But he does want to build a navigational shell that embraces the home page, so people begin to consume the new CSS – that is a great starting point.  During his engagement with Marriott, the booking path is where the organizational power is, so he focused on those aspects of their site.

In 2006, Sun Microsystems had a component library – they were perhaps ahead of their time!  But it was built by an overlord (with some help with Frog Design), and it required that people wait for him to be available to build what they needed.  That solitary model doesn’t usually work.  There is also the option of a centralized team, which has it’s pros and cons.

Leah Buley talks about design systems as being a commitment, so you have to make it a job that pays.  Ensure that the people that are serving that system have the right skills, e.g. voice and tone.  How can you federate influence so that the broader organization can be engaged?  Nathan’s recommendation (which was echoed mulitple times in the morning discussion) is that you should have a central team which treats the standards as a product, with a backlog.  That answers the inevitable questions about “when will it be done?”.  It also requires connectors, and a way to arrive at decisions with that community who is invested in the outcome.

Nathan shared a great blog post which was referenced in a few talks, called The Sliding Scale of Giving a Fuck:

What I liked about this (and I’d like to see implemented in my own team) is that when the work is so expansive  – and yet so detailed – you have to pick your battles.  Having a common language for doing that is just terrific.  Plus, a little potty mouth helps  keep humor in the situation and allows everyone to let off some steam.  🙂

Another key consideration is to make sure you have the right leaders engaged to influence and have their perspectives heard.  As with any product, you also have to have the right balance of doers and delegators.  You may actually have someone with the job of product owner of the design system.  The alignment work is hard, but it is a critical part of the job.  A Style Guide is an artifact of a design system, but the system itself is “a living, funded PRODUCT with a roadmap and backlog, serving an ecosystem”.   I found this way of reframing the work to be incredibly useful, and I’m looking forward to bringing it back to my team.

Full Stack User Experiences: A Marriage of Design and Technology

Dawn Ressel works at Intuit, she has some great ways of thinking about the measurable impact of design systems.  

Dawn launched right into an interesting talk about her work at Intuit. She is part of a central organization that builds reusable components.  Given the opening keynote presentation from Greg Petroff about the move towards a component-based architecture, I was curious to hear how a company like Intuit is tackling that challenge.  Her case study was about a Single Sign-on (SSO) capability, and the external fraud pressures that resulted in their solution eventually being implemented universally in all the Intuit solutions.  There were three really important takeaways (at very different levels of detail!) for me:

1. For designers, the medium is code – if it’s not in code, it’s still a figment of your imagination
2. The solution they built was a full-stack widget
3. The widget had it’s own built-in analytics which enabled them to learn and adjust quickly

Dawn described the evolution of UX thinking on this topic, and how they  started by thinking about pattern libraries, which is basically documentation that needs to be somehow enforced.  But at Intuit, there are 4K engineers would be required to read the documentation, interpret, and they would end up building it differently.  And then, we started to think about component libraries (which they describe as styling code but no business logic).  In this case it’s progress, because you are not relying people to enforce it, and it has re-usable elements.  But their aspiration is what she called widget libraries, which are objects that are functional on their own, and re-used in many places.  By building them they have been able to propagate best practices in terms of both technology and interaction design.

Their main guiding principal was that there needs to be a single source of truth – in code.  

And of course, it needs to scale in order to have impact.  The reality is that the only way to achieve cohesion and scale is to have that single source of truth.  For example, the Google Maps widget works on the Weather Channel, Yep, Redfin, and more.

So she and the team she is working in are thinking about widgets as the next evolution in the design journey.  The company’s mission has stayed the same, but how they have accomplished that has changed.  They have lots of products with different histories, code bases, and even cultures.  The shift from CDs to the cloud put competitive pressure on Intuit, and that created new opportunities that they couldn’t take advantage of before.  Now, instead of a set of disparate products, they could create infrastructure that enabled them to share the data across products, and connect them in a new way – thus, they had something start-ups didn’t have.

So this project called One Intuit Identity was started in a central technology group, where they solve cross-product problems.  Their first scenario was to connect users of Mint, QuickBooks, and TurboTax.  They needed to unify with best practices, thereby also creating efficiencies.  Their priorities were based on key scenarios, such as pulling data from QuickBooks into TurboTax. Here is how it played out for them:

They started by developing an Account Recovery widget, which enabled users to recover or reset their password without having to call Customer Support.  The team analytics in to the widget, so the data they collected enabled them to experiment and eventually improve the recovery process by 10%.

However, their QuickBooks team had different design patterns, and they were worried about confusing users with the new feature.  Negotiating around design rationale didn’t get enable them to progress the conversation, so Dawn’s team ran an A/B test.  Overnight the Quickbooks team had a 13% increase in customers’ ability to self-serve, and once in production, they experienced a 52% reduction in related support calls.  This was eventually quantified as a $560K savings in customer support.  And of course they improved the customer experience with the new self-service capability.

Dawn believes that this work was only possible because her team had deep subject matter expertise on identity, and fraudulent activity – they had been thinking about those problems and already had developed some code.  But they had decided not to launch the new capabilities due to the proximity to tax season.  However, due to governmental pressure, they did implement it, and they saw a massive reduction in fraud in just one week.  Now 150 Intuit products are using those capabilities, and some of the code has been made available through open source to combat fraud on a larger scale.

Based on her experiences, Dawn had a number of great insights to share:

• Their principles for a widget (1) needs to be reusable (2) demand- roughly 1.5 times more investment to build something re-usable, so we want at least 3 adoptions (3) ROI – we have a more reliable way to connect to our banking partners, and the upgrades come with nominal effort (4) specificity – document upload and document import widget are actually separate.  These are more than just an interface – they have back-end code, and build-in analytics.  The widget has multiple flows, but it was designed and built once, but it can be used many time over.

• These are not a replacement for component libraries.  At Intuit the flagship products have different style guides, so the widgets consume those styles.  The combination allows you scale the intent of visual and interaction design.  This requires close collaboration with technologists and with business leaders.

• For working with engineers (1) paint the picture, get them excited about the vision (2) don’t start with the how – start with user needs (3) get them to understand what the customers are experiencing – that is magical, it unleashes innovation (4) give them a tough challenge (5) listen and have empathy for what motivates them (6) build credibility by being specific and accurate.

• When building your team, consider that creating full stack UI widgets requires different skills from a traditional product designer.  It really requires a true systems thinker – across product and user boundaries.  It requires a deep curiosity on the domain – like security.  And that designer needs to be able to communicate their rationale across the organization in an influential way.

In closing, Dawn said that widgets (going full stack) is the evolution of the design system, but it requires thinking both broadly and deeply.  As designers, our medium is code.  Until your great design is in production code, it is a figment of your imagination!  So you should ask your self how you get designs into the hand of your users, as efficiently as possible, while still preserving design intent.

An Organizational Story: Salesforce Lightning Design System

Nalini Kotamraju is the Director of User Research at Salesforce.

I enjoyed this presentation because we use the Salesforce platform for opportunity management, outbound marketing, and for technical support.  I built the business case for and was the business owner for the technical support implementation early on.  It was relatively quick to implement, and that enabled us to start realizing busienss value quickly.  We especially appreciated the ability to connect to our customer master data sitting in SFDC, and we liked the ability to integrate it with other systems (like SAP Finance) over time.  After many years of working on SAP on premise implementations, it was clear to me how different this project was!  However, while it was pretty quick to implement, as our organization matured we did (and still do) have our share of challenges in making the solution truly usable for our employees.  I know that it really only works because the users are super technical – I don’t think we would have been successful at all with business users.  But based on my own work on multiple product suites that were built over year, I could appreciate that they were facing a huge design challenge.  I was curious to see how they tackled it.

Nalini has spent a lot of time studying how people use technology in corporations.  As a sociologist – like Sam Ladner – she is interested in who benefits, what is the motivation?  That is what this talk is about – when a research encounters a design system, in this case the Salesforce Lightning Design System (SLDS).  Her presentation is based on empirical research; she conducted research with designers, engineers, and with executives.  Three themes emerged which she is going to talk about today.

As many of us already know, Salesforce is building platform.  It was originally targeted at salespeople, and the original claim to fame was being cloud-based.  And then the message was that you could know more about your customer – not just CRM, but service and marketing as well.  And then dashboard / analytics.  It is now expanding into Internet of Things, and communities for internal employees.  So it is now is a large ‘customer success platform’.  There is a core group of people working on these topics, but through acquisition the team has become more far-flung.

The Salesforce Lightning Design System (SLDS) was born in the core product team.  The company had had the same UI for 17 years, and the introduction of a design system coincided with the development of a new user interface.  It has been a good year for the design system, especially as it regards the people and relationships.

Unlike Google Material Design, the creation of this system was a top down driven event.  Designers were trying to solve the right problems, and there was a fair amount of grass roots hustle before buy-in was achieved.  That bottoms-up style tends to be the Salesforce way.

What do people need?

Tata was exploring how they could make cheaper cars for emerging middle-class Indian families.  But they focused on solving people’s problem and needs – specifically the family moped.  What would be the substitute?  Based on their user-centered focus, they introduced the Nano.  Similarly, at Salesforce, they asked what people within the SFDC community needed.  An early mobile app (S1) came into this early version of the system.  Dreamforce is a large celebration of customers, and it’s an opportunity to hear from customers and partners (third-party implementers).  From that they learned (through the activity around the S1 app) that they wanted to make it look more like Salesforce.  How do we make it easier for our customers and partners to do that?

Salesforce has grown and acquired companies and their code.  How could they best provide consistency across the offerings?  And to address the needs of Salesforce employees?  The gap between the design and build was the biggest challenge.  The developers didn’t want to deal with the CSS, and all the problems generated all kinds of ‘fit and finish’ bugs.  So the solution needed to close the gap here, allowing the fidelity of the designs to remain intact.

How do we establish trust in the design principles? 

• How do we achieve the best possible outcomes for our end-users?
• How do we establish trust within the Design Systems Team?

The answer was simple – they had to show people where they were headed – not just tell them.  That helped to create shared understanding, and momentum.

Sharing with people, lots of people

• Share often and document
• Trailhead is a consumer-friendly way to learn about Salesforce; the team plugged into that to reach both internal and external audiences
• They made their work open source, which ‘made all the difference’, likely because of the large ecosystem of partners they enabled
• They incorporated and iterated on internal and external feedback