From the talk of the same name given first at UX Cambridge 2016.
An exploration into the creation of a design system, and the unexpected consequences for the field of UX.
UI:UX Design and Empowerment Strategies for Underprivileged Transgender Indiv...
Beyond usability
1. Beyond usability 🚀
UX Cambridge 2016
Jonathan Roberts
User Experience Designer
@touchdeluxe
“I invented the term [User Experience]
because I thought human interfaces
and usability were too narrow”
- Don Norman
(http://adaptivepath.org/ideas/e000862/)
2. @touchdeluxe
Introduction ▸ Design systems Beyond usability
Credit: Airbus and David Benjamin/The Living, an Autodesk Studio
https://medium.com/ideas-by-design/why-design-is-going-to-become-a-team-sport-for-humans-machines-9ba22e1a4aa3#.cogyvwtto
http://www.autodesk.com/customer-stories/airbus?_ga=1.196619116.1704246085.1473709732
3. An overview
About this talk, what we’re going to cover
↓
Design systems
Why they’re necessary, how to start building one and mistakes to avoid
↓
Beyond usability
What you should be doing with your new design system powers
@touchdeluxe
▸ Introduction Design systems Beyond usability
4. Me
I’ve been designing products for ~10 years,
mostly enterprise software and consumer IoT products,
always client-side within the engineering/product team
@touchdeluxe
▸ Introduction Design systems Beyond usability
10. @touchdeluxe
Introduction ▸ Design systems Beyond usability
Credit: Google Material Design
https://medium.com/ge-design/ges-predix-design-system-8236d47b0891#.hth8jo41p
11. @touchdeluxe
Introduction ▸ Design systems Beyond usability
Credit: Mina Markham
https://medium.com/git-out-the-vote/pantsuit-the-hillary-clinton-ui-pattern-library-238e9bf06b54#.wci8t5uz1
12. @touchdeluxe
Introduction ▸ Design systems Beyond usability
Consistency
“It’s a coordinated effort to apply a
common design style to everything we do”
Credit: https://www.red-gate.com/blog/building/honeycomb-design-style
35. Critical mass of 3
@touchdeluxe
Introduction ▸ Design systems Beyond usability
Credit: https://www.youtube.com/watch?v=GA8z7f7a2Pk
36. Your new Design System
(and how to take advantage of it)
@touchdeluxe
Introduction ▸ Design systems Beyond usability
37. @touchdeluxe
Introduction ▸ Design systems Beyond usability
Think abductively
The most likely one is probably the right one
Resource: http://www.jonkolko.com/writingAbductiveThinking.php
53. Beyond usability 🚀
UX Cambridge 2016
Jonathan Roberts
User Experience Designer
@touchdeluxe
Thank you!
Editor's Notes
Hi, I’m Jonny
Thanks for coming along
Going to talk about going beyond usability in user experience
This is an example of generative design
An aeroplane partition wall produced by airbus, using Autodesk software
Algorithm using rules found in nature (mammal bones) and constraints (the necessity for strength)
Software produced a more efficient part (45% lighter, less fuel burn, more profit for airline)
It’s not too much of a stretch to imagine
Maybe we’re a little way off widespread generative design in UX design
The same outcome is possible with a design system
Today: explore design systems
Tell you about how we put ours together, and what we learned
Talk about how I’ve benefitted as a UX designer; what I’m able to spend my time on now
Designing products for nearly 10 years
Enterprise software and consumer IoT devices
Always client side (in house) and usually in the engineering team
These are my biases
I work at Redgate, we make software for database professionals
We’ve got something like 30 products to help people do that
You don’t have to look long before you come across a blog post about organisations and their design systems
Salesforce’s “Lightning”...
Airbnb have one called “DLS - Design Language System”
There’s Google’s material design - of course
GE Predix Design System
Even one called “pantsuit” - presumably for Hillary Clinton’s presidential campaign
All of these organisations explain ‘why’ and ‘how’
The why is almost always about consistency
And that was true for us too - this is how we characterised our efforts
But I also want to talk about some of the unexpected benefits as well as the implications for UX too
But first, a quick refresher on the anatomy of a design system
This is Brad Frost’s “Atomic Design Framework”.
Atoms: html buttons
Molecules: label, input box and button
Organisms: header
Templates: structuring examples
Pages: real world combinations
So this is how we built ours, plus a few of the things we learned the hard way
Despite several years of the efforts of individuals, we made no progress until three things happened
A technical foundation to build on - our web framework
Internal marketing
C-level support from the CEO and the CTO
We thought our best chance of making a success of this would be to compress our efforts to get Honeycomb built, into a single week
So that’s what we did, we booked out an entire meeting room for a week, picked components off a list, designed them and then built them
But that wasn’t all we did, ahead of the week we managed to coerce one or two people, from two or three engineering teams to take a sprint to implement Honeycomb
Designing then building components and then seeing them put into place in our products for real an hour later meant we got a really nice tight feedback loop - that gave us confidence that the Design System could work technically
Where it didn’t, the engineers fed that back to us
Convincing project teams to use a whole sprint on Honeycomb wasn’t easy, so we bribed them with actual Honeycomb
We made the progress visible through updates on dry-wipe boards in our Atrium
The whole company got to see everyone’s progress - we were building our design system, and those products taking part were beginning to look more modern by the day
Of course, Design Week didn’t happen by accident, we had to prepare for it
From a Design Perspective, this was one of our most crucial activities - a sort of UI audit of each product
How it looks now,
and it could look in the future
That helped us prioritise each of the components we’d tackle in design week
The criteria being - which components are used most commonly used
We worked at an atomic level - buttons, links, type, with one exception - headers
This felt like a combination that would give us the most return for our efforts
We also enlisted the help of Nathan Curtis, co-founder and principal of EightShapes.
Nathan did two massive things for us:
1) he helped us build our design system
2) but most importantly, helped us communicate the value of a design system to the rest of Redgate
One of Nathan’s techniques for kicking off a Design Library project is his Component cut up workshop, a much more comprehensive version of our preparation -
It’s purpose is really to effectively audit where you are right now, understand the scope of what you’re about to embark on.
So, I think we should have a go at that, that’s why there’s paper spread across your table.
This is something we’re all going to do individually, and don’t worry, it’s not difficult.
I’ve compressed this into a 10 minute version, which really isn’t enough to cover everything, let alone do it justice, but hopefully enough for you to understand how beneficial this activity is.
Ok, in front of you is a bunch of screen grabs from Tesco’s website - take a flick through.
I want you to pick out an atomic component: A button / link / tab / labels / help icon / hint text etc
Has everyone got one? I’m going to go with this button.
Great
Now, grab a pair of scissors - I’ll give you 5 minutes to go and find all the other examples of the component you’ve chosen
If you’re not able to use a pair of scissors, grab a sharpie and begin to circle all the examples
----
Keep the bits you cut out in a safe little pile to one side
You don’t have to be too neat with your chopping up skills
You’ll notice that there’s a few variations in design, but the Tesco brand is strong
I chose this example because it’s very similar to what we at Redgate faced
It’s not a comment on Tesco by the way - does anyone here work for Tesco?
---
Ok! Time’s up
Move all your discarded paper out of the way and put your components back in front of you.
Now look at what’s in front of you
How much variation is there for your component?
Our task now is to group them together -
So for me, with these buttons I’m going to think about their types: I think I’ve got primary actions like “log in”, and secondary actions like “cancel”, but I’ve also got a button with a icon of a dog on it
Take a few sticky notes and a sharpie and give your groups some labels
So my groups are primary, secondary and novelty
---
Now I’m looking at this novelty group and I’m wondering, why does this exist?
One of Nathan Curtis’ suggestions is to label each of the UIs on the back, so you can trace their origin
In this case I might want to take a wander over to the pet insurance team - “hey guys, what’s the rationale behind this button with a dog on it”
And they’ll probably give me a good reason - people fill out the form quicker with that button
Great, now I know that it’s not just an arbitrary decision, that type of button is going in my design system
Now I can consider the different states for each of the types - active, inactive, hover, in progress
And that’s it, I’ve audited one component, all I need to do now is design and build a single instance of each type, and give instructions for behaviour for each of the states I need
---
Ok, enough fun, let’s put our pens and scissors down
So, there are lots of things to consider, and that’s long before you get to accessibility and interaction requirements.
Let’s take a really quick look at Redgate’s Design System Honeycomb
Honeycomb has seen great traction
It’s become a verb
But the more it provides, the more new things are needed from it
We’ve not got a dedicated team on it, and it’s suffering, both in terms of providing for its users but also their trust in the design system itself
A lot of the design systems you read about describe in great detail how the UI tech works, or the tech stack it’s built on
We can’t do that - 1) we’re not best placed to make those engineering decisions, 2) we won’t be able to provide all the UI in all the technologies
If you’re anything like us, then your UI tech is going to different from product to product - avoid prescribing a single tech stack if that’s the case
So what do you do instead?
Provide a pattern to copy.
A few months ago this little brain teaser appeared on the wall near the coffee machines.
I’ll give you a couple of seconds to read it - can anyone tell me what comes next in the sequence?
The answer is 312211
The subsequent number describes the previous one, so in this case, the previous number had three 1’s, two 2’s and one 1 - 312211
If I asked you to continue the sequence for another 100 goes, you could.
My point is, not only have I given you a few examples of the pattern in use, but I’ve also explained the rules - now you can continue the pattern as long as you need to!
Consistency for consistency’s sake is bad.
Or at least it should be carefully considered, because sometimes there are unintended consequences….
To give you an example, we wanted to update our product logos so we could achieve consistent brand recognition of our tools.
The idea being, you try one tool, like it, recognise another as coming from the same place, try that too.
A pretty understandable goal
Let’s focus in on the top two products...
Here’s a bit of background -
The top left is SQL Compare - that’s for comparing database code (the stuff that defines the structure of the database)
On the top right is SQL Data Compare - that’s for comparing the data within the database
The top row gives you an idea of what they did look like, and directly underneath them what they were changed to
There’s a whole talk in the rationalisation behind the iconography, but the key thing is that where one used to be blue, and one red, they’re both red now. So yay for consistency.
Except for this user, who missed the colour change (and the fact they were looking at what is a different UI)
And ended up wiping out an entire day of a team’s work.
Critical mass of three - what’s that?
It’s a bit like this guy dancing by himself, looking daft for a while until the second guy joins in (still looking a bit daft), and then at the point person three shows up, the dance movement is really gaining traction
We discovered the same thing - we found our critical mass at 3 products - that is, as soon as the third team joined in with the Honeycombing, the rest followed quickly.
Ok, a small confession - I’m not an expert in design systems - I was just there in the background while one was created.
But what I have become an expert in, is how to take advantage of having one ;-)
So what new powers do I have?
I’ve been able to start thinking abductively
What does that mean?
Thinking abductively is the method of reasoning that suggests that the most likely explanation is probably the right one.
So what that gives me, with a design system supporting me, and a knowledge of how things have worked in the past, is a confidence to say “you know what, if we put these things together in this order, it’ll probably be right”
And that’s opposed to what I did previously which was sketch, design, usability test, iterate designs, hand over to development teams
It’s a bit more complex than that, but I truly believe the design system has helped get me there
There’s a good link to abductive thinking at the top - don’t worry, I’ll post the slides online later
And so our design system combined with abductive thinking means I can get away with this level of design detail for an entire sprint
Just a terrible sketch on a scrap piece of paper, blue-tacked to a wall.
Most of the time, the team engineering the interface can reference the design system - I barely need to be involved
The thing is, less of my time is now spent in planning, running and writing up usability calls (still important by the way)
And I’m no longer lost in Illustrator for days at a time.
And people will start to ask - erm, what do you do then
So let me tell you which areas I think we, UX professionals, should be contributing to more heavily too,
What we should be doing beyond usability
Team learning - really important
Become responsible for it
Agile’s great, but it’s a bit like swimming without goggles
feature, feature, feature….SLAM into the wall
12 months later you look up and you’re in totally unexpected place
Learning as a team helps prevent that by being aware of the answer to the question “why are we building this?”
I’m yet to work in a team where there isn’t at least one person with at least one burning question
One of the things we do from time to time, is take an hour or two to get together and get all those questions out
Discuss them out in the open, agree on the things we just don’t know about
Capture those questions in any way you can, because behind those questions is intrigue
Once you’ve got questions and intrigue, you’re ready for a process that’s entirely designed to get you those answers - Lean UX
Buy the book - it’s pretty prescriptive
---
Fortunately there’s a nicely prescribed process for that… Lean UX
- Capture assumptions
Use those questions to capture your assumptions - things that you think are true.
- Build hypotheses
With them, create your hypotheses - these are things that you can prove to be true, when you’ve received the validation signal you’ve been looking for.
For example, we hypothesised that users of a particular database editing tool had data in a development environment, that differed from the production environment - in order for us to know that is true, we wanted to hear it from the majority of people we spoke to mostly unprompted (that was our validation signal)
- Create call plans
Now you can build a research plan - with the team - to convert those raw questions into great research questions (non-leading, open, un-biased etc).
Then the rest of the lean UX process prescribes the loop
- Learning logs, - Decision making
Capture learning and decide on what to do/build
Then iterate through the process again, this time with your new questions (you will have them).
A couple of extra pointers:
Create a learning log and make it visible - so useful for team decision making
The Lean Board - get your process up on the wall, visualise your learning
Coercing people to calls - try some soft metrics like %age of team in call this month to encourage attendance
Finally, remember that this kind of research isn’t usability testing - you’re going to find out stuff you never even knew about, you’re going to have to hold a lot in your head.
One of my new favourite ways to capture that information is with a Rich Picture - like this one
Rich Pictures were developed as part of Peter Checkland’s Systems methodology for gathering information about a complex situation
They’re part of a wider area of study called “Systems Thinking” - several talks in themselves, but the idea is that we can use them to map out the ecosystem we’re researching
A lot of the time, it’s understanding how our product fits into that ecosystem
Innovation can seem a bit like magic, or gravity I’ve no idea how it happens, or how to make it happen, but it’s obvious as soon as someone explains it
There are two ways I think we can help innovate
The first is through really improving the experience of using a product
I took this sketch down during a talk Jared Spool gave recently
It’s a journey map
On the y axis is emotion, from frustration at the bottom, to delight at the top. Somewhere in the middle is “meets basic expectations”
On the x axis, time
And plotted on the graph, two lines
The dotted is our current user experience
The solid is our potential future user experience, busting through basic expectations
That gap, the difference, is, Jared says, potential for Innovation
Something that I found hard to take on board until you consider that the “basic expectation” line is forever rising - so it’s a constant game of one-upmanship
---
Example of this
The second way we can contribute to innovation is through speculative design
What most people would probably call design fiction
This photo was taken during a Redgate Down Tools week - a week where we stop working on our own projects, and start working on a one week project, usually something totally different
In this case, I worked with a Redgate spinout called Gearset, to really explore the future of their application beyond the current sprint.
Forgetting about all the constraints for a week, and in fact giving into loads of assumptions, it’s surprising how many ideas you can product
This example, for Gearset, that company is still using a lot of the work from that week
This is the final thing on my list of things to do with all your new found spare time - upholding your principles.
I’ve found myself, on so many occasions getting dragged into tactical decision making - “we’ll just do that for now, and come back to it”.
I’m a sucker for it, I believe them every time.
So I’d like to make a strong case for taking the time to think about your design principles, get them down on paper and train yourself to keep them upheld
These are mine,
I’ve chosen these because
I think they’re important
They’re easy for me to recollect daily basis
I also think they’re achievable, and not in contention with our other goals
To come up with mine, I thought about my basic expectations of software (because software is our tangible part of the product)
They are that
- Users should be able to recover from mistakes
- More than that, we should do our utmost to prevent mistakes
- Our software should Imbue trust - that’s our users having trust in us, and actually, in products with multiple users, they should be able to trust one another
To do that, I think our software should
- Facilitate (good) conversation between users
But that’s very specific to our software with multiple users
So that’s it
Hopefully that gives you a new angle on the value of design systems
I hope it also gives you some ideas about the direction UX could move in for your organisation so that it continues to be a valuable pursuit.
Thank you very much for listening and taking part.