Getting Good UX Into Mobile
•Download as PPTX, PDF•
10 likes•2,023 views
Originally Presented at Mobile Trends 2014 in Krakow, Poland on 16 January 2014 Almost all mobile apps fail to make back even their development costs. Add user-centric tactics and principles to help you understand users and their needs, and validate your ideas before you spend the time.
Recommended
Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (20)
Similar to Getting Good UX Into Mobile
Similar to Getting Good UX Into Mobile (20)
More from Steven Hoober
More from Steven Hoober (20)
Recently uploaded
Recently uploaded (20)
Getting Good UX Into Mobile
- 1. Getting Good UX Into Mobile A few tools & techniques we can all use @shoobe01 #mtc2014 1
- 3. Photoshop! 3
- 4. 4
- 5. Okay, you go find me an ecosystem developer. 5
- 6. Tools to design experiences: 6
- 9. KJ (Post-It®) Process: • • • • • • Determine focus questions Get everyone in a room Answer questions Put up answers Group answers, label groups Vote on most important groups 9
- 10. 10
- 11. 11
- 12. 12
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. Design and review at device scale. 18
- 19. 19
- 20. 20
- 21. Thing 21
- 22. Don’t just draw, specify. 22
- 23. 23
- 24. Embrace failure and complexity. 24
- 26. 26
- 27. 27
- 30. “Error is viewed, therefore, not as an extraneous and misdirected or misdirecting accident, but as an essential part of the process under consideration.” – John VonNeuman 30
- 32. PHOTO. REG CODES ON CEREAL BOXES. 32
- 34. • Define, then design. • Design ecosystems, not websites or apps. • Don’t just draw: specify. • Design at device scale. • Embrace failure and complexity. 34
- 35. And, ask for help. 35
- 36. Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 045 @shoobe01 shoobe01 on: www.4ourth.com 36
Editor's Notes
- It seems like just yesterday I had to start every talk, and every piece of work with a client, with an explanation of what UX is. And while we now value good experiences, there are still many misconceptions, which too often lead to wasted work, and unhappy customers.
- One trendy method these days is that every developer is now a designer. Instead of working as a team — or as they always say: waiting for a design to be completed — there’s a concept of “sketching in code.” As Artur just showed us, you prototype, first, and as fast as possible. You hire a designer-slash-developer who does it all, at once.The value is that there’s no delay between design and code, and even if you can’t use the prototype for production, at least we know what it will look and work like.
- This prototype-first method is specifically a counter to what they call “static design” by which everyone seems to mean Photoshop. They used to mean Firework, but that died. Wireframes in vector programs — Omni Graffle, Visio, InDesign, Illustrator — are also included in this, and if you push some people, dedicated prototype platforms that aren’t real code, like Axure. The theory is that taking time to design is inherently bad because no one has the time, and anyway who are these designers to tell us what can be built?
- The theoryreally is that we should all be unicorns. The mythical creature is as rare as the perfect employee who can code, AND design, AND consider the user, AND keep in mind the needs of the business… etc. A lot of people point out the obvious flaw, that we are not all built that way, and people have core skills. I and many, many others argue that specialization is good. I am a designer, but have no doubts: I have been a web developer, and even a DBA. I have managed teams of developers. I was not as good at those jobs as I think I am at being a UX designer, but I know what I am talking about, please don’t think I am just anti-developer. I am even told that empathetic tasks (thinking about the user) cannot, fundamentally, be done at the same time as systematic or analytical tasks (building technical systems). A team approach solves this.
- But there’s a bigger issue, and this is in some ways my central thesis today: You cannot quickly code up an ecosystem. Even a website has datastores, middleware, APIs. And if you start at what’s now being called API-First, you quickly realize there are dozens of platforms, from the web, to email, to text, to all the various app platforms… The right way to design, the user-centered way, is NEVER to say on day 1, “we’re making a website” or an app, or any one technical solution. Your solution may not even be digital. Will a sticker solve the problem? Or a poster? Or a change in business process? If you start with code that you are comfortable with — and for these arguments it is always HTML — that is where you will end also. You will never make anything better than a website. Even Twitter, famously an SMS based tool, has become a Web tool and recently realized this is a crisis; customers aren’t using their own apps as much while Twitter took their eye off the ball.
- And that’s what I’m going to talk about today. A handful of key tools, techniques and practices for (mostly mobile) UX design, with an emphasis on the U and the X… …but even when they are about interface and interaction, not so focused on UI, or platform details, or anything else that you get bogged down and miss the big picture.
- I came to many of these realizations and convictions by massively failing and wasting my time. I re-confirmed it recently, building a very beautiful product that’s somewhat odd and disjointed. Though we are working on it. Because if you go to drawing too early, you get locked into interface and interaction decisions. The first thing to do when designing is to resist the urge to draw at all. Instead, we need to understand, and define.
- And you define, the basic outlines of your product. This is similar to the writer-like questions that Monika outlined earlier. What is your audience?What are their goals?What are they using now to solve this need?Why is your organization doing this?
- If you get a team together who have been working on similar products, or have been talking to customers on the first, old or even failed version, they have a lot of knowledge in their heads. Annoyingly, it’s INSIDE their heads. And people are bad at analyzing and sharing really. But, we can use this technique to extract the information and find really, really interesting answers as a result. So, we make this team answer questions, briefly, and share the answers. The KJ process is a psychology trick, basically, where you make everyone work together, so they lay out their information and they COLLABORATE on the answers. Not because you ordered them to collaborate, but because the process leverages group behaviors to extract information and foster collaboration, naturally.
- When you are done, it will look something like this….It’s best to do it on a whiteboard, so you can revise the circles and labels. Here we used index cards and tape, instead of Post Its for some reason. Same thing, and it works fine. When I mentioned “tricks” before, I mean things like only giving the participants small pieces of paper and markers instead of pens, so they cannot write too much on each card. NOW… what you get out of this is not just team building. None of these techniques I show you are dead end exercises. This one should evolve naturally into vision statements, business objectives or other high level goals that you may have been struggling with.
- Remember it is a group exercise. Here, I am also using the principle of stuffing cards on a wall in a different way, as the client had issues with understanding priority.The rectangle is an x-y grid, with relevance and frequency. Items in the upper left we definitely build.
- Or you can model system behavior at a very high level. Here, the client group working on it had a LOT of knowledge about the business process and how the customer worked. Gathering that integrally with the data collection worked great here, and we were able to turn this into a process diagram later on.
- Because the next thing is really to model the ecosystem. We still do not draw. Well, not screens at least. You will make things like storyboards and flows to identify and define how the user can discover, enter, and employ your system as a part of their everyday work or life. I can think of this also as “modeling the experience.”
- Anyone who wonders why I am not talking about mobile, it’s right there. And so are computers, paper, and collaboration with friends. Mobile has made us aware of the digital and social ecosystems in which we work, but don’t go make an app without thinking like this. Storyboards are one method to make you think about processes from entirely the user’s point of view. Storyboards are a great way to force yourself to think about users, their context, and their behaviors off the screen. Or as I said earlier, to think about creating an ecosystem.
- Sketching is a great way to model an ecosystem. Not by sketching pages,but the interaction between processes, and tools. You can include all platforms, or ignore platforms entirely as we did here. Remember, users don’t see your sitemap so it can be infinitely complex. Only the interface has to be beautifully simple. But if your tool is SIMPLISTIC (feels dumbed down) people notice. Don’t remove features to find simplicity. The right design will emerge.
- When you write, or draw concepts, they should talk about services, data, sensors, networks and users. Tasks, not screens. Don’t just put your vision statements, goals, and objectives on the wall, or on the first page of the deck, but bake them into the diagram. This is what I think of as a Task Map, and my Customer Journey Maps look similar. With no start, no stop and no happy path. Lots of circles. Your customers and their experiences are a long-term investment.
- If you absolutely must show off screen designs very early — and this happens to us all — do something like this. Draw comps parallel to a storyboard, or like this with bits of the user and context. And, even here you don’t need to settle on a single platform for even this step. Here, it’s SMS, notifications and apps. Sketched out as part of the user task.
- How many of you draw on a computer? Or, present your designs to clients or your team or boss in a conference room on a big projector? I am sure all of you…
- Better is to work at device scale directly. Draw on printouts the same size as your device. Mariola and Tomasz this morning showed off sketching on paper, and their sheet is nice, but it’s not quite to real-world scale. You need to make (or download from me) these sorts of things Put designs, low or high fidelity, into the phone’s gallery (you can just email comps or photos to yourself) and flip through them, as though it’s a real interface. ** HOLD UP PHONE **Pass the phone around the room to show it to clients. Run it by users to test it out.
- Besides getting the general impression of how it works, you can directly check specific guidelines. You can use specifications I and others have developed to make sure your text is readable and your targets are clickable without doing math or guessing. Just hold up a circle template or this tool I had made up.
- If you do create a real multi-device ecosystem, you are going to have to do this with each class of device. Here I am testing the actual product on everything I have. If this looks complex compared to how easy it is on the desktop web, you probably have just been ignoring a bunch of users on other platforms — or other desktop browsers, or other screen resolutions — already. Fragmentation isn’t a bad word, it’s just about supporting user choice, and well-designed, well-built products don’t have as many issues as you might expect. If it looks expensive to have lots of devices, there are shortcuts. Device Anywhere is worth writing down, as a way to not have to buy a big pile of devices, and even to automate some of the testing.
- Looping back to the argument about prototyping, one key complaint is that you can’t tell how a drawing will work. Of course not. So I don’t do wireframes, or god forbid comps.
- I write UI Specifications. Half the page is occupied with details of how the interface works, how it should be built, and what the user can do to it. This often means much less work for developers, as I give them the sizes, colors, methods of movement, timings, opacity, and everything I can. Usually, already translated to the platform, so Android gets SPs and DPs, not pixels or inches. Monika also mentioned in her animation example how prototyping helps. And you can sure make a sample to get the animation nailed down. But then write down what the results are so the developers can implement it right, instead of guessing. There’s not a bit of ambiguity, which easily emerges even from turning a prototype into real production code.
- …Everything you design and use is too complex to adequately model and map. Assume you have always missed something, so you are prepared to deal with the unexpected, both in design and so you can modify your product over time to take advantage of new ways you find people using your information.
- Resilience engineering is a practice, initially for structural engineering, but now used by people like Yahoo! Etsy, Amazon and Google to keep their servers running. Brittle systems are like a brick building that when an earthquake hits goes from the state of “building” to the state of “pile of rubble.” A resilient system is like a wood framed house, which accepts the movement and does little more than wobble. When Amazon or Google has a server go down, or a server farm, you will generally not even notice. By design.
- I say there’s something called Resilience Design. Or there should be. Here’s a simple example… Besides my smartwatch,I also still wear normal watches. One is a dive watch, because it’s shiny, not because I am a diver or anything. It is one of those with a twisty ring around the outside. That part with the numbers twists around. If you don't know, and I didn't until recently, this is used as a simple timer. On aviators watches, it goes both ways, but on mine, and on all dive watches, the ring only goes one way. The clicky detent lets it go counter-clockwise, only. Why? … Because it's for timing remaining air. The ring might get bumped and change it's setting. Having it show less time might be inconvenient, but going the other way might kill you. And as a user, you don't even need to know this. It just works. That's the sort of brilliantly-simple answer I am talking about with resilient design.
- From our point of view, you can design the IA and interaction to not be brittle at their core. How many websites assume we all land at the Home page and drill down? Almost all. But we know perfectly well that’s not how it works. Search is critical so we enter in the middle of websites, and even for apps and non-web interactions, increasingly start in the middle of tasks we started in another channel.There is no “happy path” and you cannot design straight line routes and assume everything else is an error.
- Right now, technical systems (software, data) fundamentally expect perfect information and absolute precision in computation. They are intolerant of imprecision, missing data, and failures to connect unless that behavior is also precisely designed.
- While people are great at estimating, fudging, and getting by, our users do not liketo use tools that break or cause them to work harder. Very simple gaps in “look and feel” can induce familiarity discomfort similar to the uncanny valley of anthropomorphized representations. At the very least, you will encounter reduced satisfaction and trust. Often, that means users will give up and use a competitor’s product or service.
- In 1952, computing pioneer John Von Neumann called computational errors “an essential part of the process” of computing. This was almost forgotten for decades with the advent of the high-reliability computers we work on today. But increasing amounts of data and the need for power conservation are creating a need for unique solutions that leverage probabilistic design and ignore unused data or let small errors occur in computing.
- This is surprisingly not new even to visual and graphic design. The technical methods of printing machinery have inherent inaccuracies and behaviors that make certain apparently possible designs insufficiently reliable for mass production. Print design has to account for ink being placed in the slightly wrong place, for overlaps on adjacent layers, and for slight errors in binding, folding or trimming.
- In print (and package design) these are all considered tolerances, or normal variations, not errors. Accounting for overlaps and inaccuracies in ink placement is a whole (very specialized) practice area called trapping. I have books on my shelf dedicated just to trapping.It’s baked into the entire process of print, from design through QA. These little colored boxes are “registration marks,” allowing the printers to line up the inks, and allowing inspectors to check that it was done well, and consistently.
- For us all to account for tolerances and normal variation instead of lamenting fragmentation, complexity, and error means letting go of perfect solutions to create better, more robust systems and solutions. We need to embrace the messiness and complexity of systems—and of real life. To apply these approaches to interaction design, information architecture, database design, or software development, with all the additional complexities, really doesn’t call for anything new. We already do many of these things, but need to switch from considering them as discrete tasks to seeing them as principles that are applied regularly and repeatedly throughout the process of designing any project.
- There are many other tools, techniques and guidelines to use. I didn’t even get to the really deep, tactical mobile things like talking about touchscreens. But these are principles that lead you there.
- So the last tool I suggest is to look and ask. But aside from processes, there is precise, specific and immediately-useful information out there also. I regularly find academic research that provides fascinating answers to my exact issue. And there’s a community of UX design. When you go home from this conference, don’t lock yourself in the office, but keep participating. Follow others, read articles, ask questions when you get lost. Share your own solutions and good ideas.
- And certainly, feel free to ask me questions as well.