Download to read offline
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Boring Design Stories
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. We built FancyProduct X, but for our customers to use it, they first had to migrate from Feature A to Feature B.
- 9. Boring design is hardto love.
- 10. The Lion, theCat and the Mouse
- 11.
- 12. Hey, have youtried out Fancy Product X? Yes! We need to get our teams trained and set up to use it… 🦁 🐱
- 14.
- 15. TIP #1 Tell astory Make it lovable!
- 18. STORY 2 The TechnicalTangle
- 19. We built FancyProduct X, but for any customer to use it, they needed to configure a lot of settings, some of which are quite technical. (Oh, and if they did it wrong, they’d get a whole bunch of alarming errors.)
- 21.
- 22. Called on theCustomers
- 23. TIP #2 Test, test,test your problem, and your solution, and yourself!
- 24. Set up aStructure
- 25. Discovery 🚧 Management ✅ Qualityfeedback ✅ Authentication 🚧 Account ✅ Reporting 🚧
- 26. TIP #3 Take itstep by step Lay out a map, and don’t get lost
- 27.
- 28.
- 29. TIPS Tell a story Test,test, test Take it step by step Transparency builds trust
- 30.
Editor's Notes
- #2 Hey everyone, and welcome to this session on, “Boring Design Stories”.
- #3 I’m currently a product designer at Automattic, parent company of Wordpress.com, Tumblr, WooCommerce Previously at Zendesk, messaging experiences Designed Consumer apps, websites and print media for clients like Cartier & Dean and Deluca Something I’ve discovered over the last decade, and I confess
- #4 Or, more accurately, I love designing boring things
- #5 Things people have to do or products that people need, in order to do their jobs or just live their lives A little goes a long way. Zendesk - customer service - difficult to delight in it - Can be painful / frustrating for all parties -, but it’s crucial to businesses and consumers. Consumer apps too - I’ll mention an example later.
- #6 Going to tell you 2 stories Process, mistakes & learnings 4 tips for designing boring things
- #8 This is a summary of the problem. We quickly realised - It’s a necessary evil - a can of tedious worms that no one wanted to open How long will it take? It depends. The migration will can take 15 minutes… or a few hours. Can they still use the product like they usually do? It depends. It might break if they try to do Action 1, 2, or 3, or if they are User Role 1 or 2. We scoped out the problem, realised how necessary and essential this flow was to actually launching Fancy Product X, and on the next slide, is an actual picture from one of our meetings with stakeholders…..
- #9 It’s not that no one wants to care. It’s just too complicated, too abstract, and too confusing to understand. When your team is handling a dozen other workstreams, that makes it extra hard for it to be prioritised or given resources. The response was “can’t we just do the bare minimum here and focus on something else which is more important / interesting / less tedious” At risk of becoming just an afterthought - that would result in a painful experience for a signifcant chunk of customers
- #10 This project is a good example of Something that I’ve learnt - boring design is hard to love. It’s hard to understand and it’s not something people intuitively connect with It is an inherent challenge when you’re doing this type of design, and you have to advocate for your problem
- #11 This idea is credited to Mike Chen, head of design at ShopBack, who was my partner on this project at the time
- #12 Came up with the idea to use three characters - “Leo the Lion, Cleo the Cat and Minnie the Mouse” - each representing a certain user role. We put them everywhere - our slide decks, our Sketch working files, our Miro board, our notes….
- #13 We put in little dialogues and skits between the three characters...
- #14 spliced that together with our interface designs and user flows Created empathy and clarity among the team Became a story of 3 people working at a company
- #15 This approach turned a very confusing and abstract flow into a story that everyone understood The results were: Buy-in and kudos from many levels of management Given the time and dev resources to design & build a more user-friendly migration flow
- #16 Creating characters Drawing comic strips GIFs Help people connect with and understand what the problem is, and what the solution could be.
- #17 Another good example from consumer software that came to mind was, Getting a new iPhone, maybe 5 or 10 years ago - you’re real happy to get a new phone but you have to back everything up through itunes (which would take like hours) and then re-sync it, which could take more hours and often would screw up for me!
- #18 Today, it’s so much easier - you can even sync the bare minimum, to start using your new phone quicker, while the rest of your data downloads in the background Think about the designers who worked on this - one of the least sexy or exciting things the iPhone does But even a small improvement, big impact to a big chunk of users?
- #20 This is a summary of the problem We had to go through 200 slides and a 2-day workshop just to talk about all the requirements!
- #21 This was me after those few days… I went down rabbit holes, got lost in notes, spent a week or so in this state
- #22 Created the extreme ideal version, “ignored” the 200+ slides of requirements. I did this to test my own understanding - Am I even getting this right? The basic flow? Unexpected result Energised the team “Looks real” Tested the team’s understanding - build shared understanding of the flow Helped to shape the requirements and sieve out what is truly required
- #23 Tested some semi-ideal versions with customers Testing overall usability Getting their perspective early on key concepts Validating some requirements - they even asked about certain technical settings which we excluded in the semi-ideal prototype
- #24 Especially with super confusing, complex, technical stuff - Make sure you and the rest of your team fully understand the scope and nuance of what you’re tackling! Test your requirements Test your solutions
- #25 You might have noticed we did this in the first project too - with the three animals :) We defined and agreed on some ‘epics’ across product, dev and design Product took this and wrote user stories Design put it into the working files - splitting up my screens and annotating them Devs used it as a starting point for breaking down and understanding tasks in Github
- #27 It seems obvious, but massive problems are much easier to solve if you split them up. More palatable, more defined, easier to tackle One note of caution - I’ve seen huge projects get split up in an isolate or top-down manner, without enough input from the whole team This can cause confusion and more chaos, rather than clarity - because the segmentation is all wrong It’s not that straightforward Needs an ongoing dialogue between all levels and functions Needs to be flexible to move and adapt as the project gets worked on, people uncover new things And expectations managed for people to know this structure might need to change The value of have a Shared language about the ‘map’ and the different areas to help you figure out where you’re going, where you’ve been, and where you need to explore - so valuable
- #28 To work in complex and tedious problems - I think you need more communication, because a lot of things are not ‘obvious’ as with other, more visual problems Designing out in the open helps people to come along with you - - Worked with open design files, Google docs, and aggressively invited people to take a look, leave comments Got feedback from not just product and dev, but also marketing, business folks, other teams who hadn’t worked directly with design before Invites feedback and prevented gotchas especially with technical aspects
- #29 Three step set-up Very excited users Ongoing project Really good feedback from stakeholders
- #30 TO recap… Tell a story: Make things lovable, approachable Test: Not just your solution, but your problem, and your own understanding and alignment Take it step by step: Be flexible as you draw your map and create structure Transparency: Communicate more, it might be slower, it might take more effort but it’s ultimately worth it when you’re dealing with complexity
- #31 Thanks for taking the time to watch this session . Looking forward to connecting with you all and hearing your own boring design stories!