![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/)](https://image.slidesharecdn.com/beyondusability-notes-160914145734/85/Beyond-usability-1-320.jpg)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Beyond usability
Similar to Beyond usability (20)
Recently uploaded
Recently uploaded (20)
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
- 5. Redgate Software-for-software-people, in Cambridge Usability was always the a differentiator… ...now it’s a basic expectation @touchdeluxe ▸ Introduction Design systems Beyond usability
- 6. Design Systems @touchdeluxe Introduction ▸ Design systems Beyond usability
- 7. @touchdeluxe Introduction ▸ Design systems Beyond usability Credit: Salesforce https://developer.salesforce.com/lightning
- 8. @touchdeluxe Introduction ▸ Design systems Beyond usability Credit: Airbnb http://airbnb.design/building-a-visual-language/
- 9. @touchdeluxe Introduction ▸ Design systems Beyond usability Credit: Google Material Design https://material.google.com/
- 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
- 13. @touchdeluxe Introduction ▸ Design systems Beyond usability atomicdesign.bradfrost.com
- 14. Building Redgate’s Design System, Honeycomb @touchdeluxe Introduction ▸ Design systems Beyond usability
- 15. @touchdeluxe Introduction ▸ Design systems Beyond usability A foundation to build on, some internal marketing and full support a C-level
- 16. @touchdeluxe Introduction ▸ Design systems Beyond usability Design Week
- 17. @touchdeluxe Introduction ▸ Design systems Beyond usability Design WeekDesign Week
- 18. @touchdeluxe Introduction ▸ Design systems Beyond usability Design Week
- 19. @touchdeluxe Introduction ▸ Design systems Beyond usability Design Week
- 20. Preparation @touchdeluxe Introduction ▸ Design systems Beyond usability Current Future
- 21. @touchdeluxe Introduction ▸ Design systems Beyond usability Design Week
- 22. Component cut-up workshop (the 10 minute version 🕑) @touchdeluxe Introduction ▸ Design systems Beyond usability Credit: https://medium.com/eightshapes-llc/the-component-cut-up-workshop-1378ae110517#.amctpik38
- 23. @touchdeluxe Introduction ▸ Design systems Beyond usability Task 1 ~ 30 seconds ~ Choose an “atom”
- 24. @touchdeluxe Introduction ▸ Design systems Beyond usability Task 2 ~ 5 minutes ~ Cut out all the examples of your chosen component
- 25. @touchdeluxe Introduction ▸ Design systems Beyond usability Task 3 ~ 4 minutes ~ Begin to group your components
- 26. Honeycomb honeycomb.red-gate.com @touchdeluxe Introduction ▸ Design systems Beyond usability
- 27. @touchdeluxe Introduction ▸ Design systems Beyond usability #Honeycomb We should have put a team on it full time
- 28. @touchdeluxe Introduction ▸ Design systems Beyond usability Implementation Avoid asserting the use of a single tech
- 29. @touchdeluxe Introduction ▸ Design systems Beyond usability What’s next in the sequence? 1 11 21 1211 111221 ….?
- 30. @touchdeluxe Introduction ▸ Design systems Beyond usability What’s next in the sequence? 1 11 21 1211 111221 31 22 11
- 31. @touchdeluxe Introduction ▸ Design systems Beyond usability Consistency for consistency’s sake… 😓
- 32. @touchdeluxe Introduction ▸ Design systems Beyond usability
- 33. @touchdeluxe Introduction ▸ Design systems Beyond usability
- 34. @touchdeluxe Introduction ▸ Design systems Beyond usability
- 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
- 38. @touchdeluxe Introduction ▸ Design systems Beyond usability
- 39. @touchdeluxe Introduction ▸ Design systems Beyond usability “...so what is it you do?” Good question
- 40. What to do? (now you’ve got all this time) @touchdeluxe Introduction Design systems ▸ Beyond usability
- 41. 1 Be responsible for team learning @touchdeluxe Introduction Design systems ▸ Beyond usability
- 42. @touchdeluxe Introduction Design systems ▸ Beyond usability Image credit: http://www.usaswimming.org/ViewNewsArticle.aspx?TabId=0&itemid=4368&mid=8712
- 43. @touchdeluxe Introduction Design systems ▸ Beyond usability Question assumptions and build team intrigue through question gathering
- 44. @touchdeluxe Introduction Design systems ▸ Beyond usability
- 45. @touchdeluxe Introduction Design systems ▸ Beyond usability
- 46. @touchdeluxe Introduction Design systems ▸ Beyond usability Resource: http://www.slideshare.net/johannakollmann/understanding-systems Credit: http://proceedings.informingscience.org/IS2002Proceedings/papers/Horan133Newan.pdf
- 47. 2 Contribute to innovation @touchdeluxe Introduction Design systems ▸ Beyond usability
- 48. @touchdeluxe Introduction Design systems ▸ Beyond usability Credit: http://www.slideshare.net/ISITEDesign/delight-2013-jared-spool-of-uie
- 49. @touchdeluxe Introduction Design systems ▸ Beyond usability Image credit: https://twitter.com/wapadam/status/662606961800781824
- 50. 3 Uphold your principles @touchdeluxe Introduction Design systems ▸ Beyond usability
- 51. @touchdeluxe Introduction Design systems ▸ Beyond usability Principles Recover from mistakes Prevent them Imbue trust Facilitate conversation
- 52. In summary @touchdeluxe Introduction Design systems ▸ Beyond usability
- 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.
- If we’ve got time, has anyone got any questions?