Tools for Mobile UX Design
•Transferir como PPTX, PDF•
11 gostaram•2,858 visualizações
Presented at ConveyUX in Seattle, 7 Feb 2014 There is a gap between the most discussed and trendy practices in design, and the way many UX professional do their work. Sketching in the browser is fine for those who only design websites (and have a coding background) but what about apps, messaging, services and systems? In this workshop Steven will outline some of the basic principles of good tools, and demonstrate with simple hands-on exercises how to use your existing software, and other simple techniques to design for multiple screen sizes, multiple contexts and every platform. You will learn: - How to consider scale, and really understand portability and touch. - Design with adaptive and responsive needs in mind. - Specifying design, so UX speaks the language of implementation. - Service and systems design techniques. - Quick techniques to assure that your designs will work in context.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Tools for Mobile UX Design
Semelhante a Tools for Mobile UX Design (20)
Mais de Steven Hoober
Mais de Steven Hoober (20)
Último
Último (20)
Tools for Mobile UX Design
- 1. Tools for Mobile UX Design Empathy, ecosystems, and scale @shoobe01 #ConveyUX 1
- 2. 2
- 3. 3
- 4. 4
- 5. 5
- 7. To design mobile: • • • • • • Don’t draw Ecosystems first Experience mobile daily Work at scale Annotate, describe, understand Evaluate, and validate 7
- 10. 10
- 11. 11
- 12. 12
- 13. 13
- 14. 14
- 16. 16
- 17. Is there an ecosystem developer in the house? 17
- 19. Thing 19
- 21. 21
- 22. 22
- 23. 23
- 26. 26
- 27. 27
- 28. Evaluate. 28
- 29. Quickest evaluation: • • • • Does the IA make sense? What about errors? What happy path? Are you lying? 29
- 30. 30
- 32. 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 32
Notas do Editor
- If you have been to other workshops here, you should understand that 90 minutes isn’t really enough time for workshops. So, I’ll talk a bit, you guys will work a bit, and then I talk more, and so on. There are 4 exercises… I think... So I will stop you from doing the exercises, so we can talk about the next phase. I will be yelling at you.
- This toaster oven, like most of them today, is a tour de force of technical design and manufacturing skill. It is packed with features, efficient, and does exactly what it says on the box.Except be usable. This is in an AirBnB rental I was at over Christmas. It took me 40 minutes to toast a bagel. I believe, because there is a clear
- Anyone coming to a conference on UX clearly believes in the power of the user. We developed user-centric methodologies, and exercise them (sometimes with “user centered” in the name no less) regularly. Almost by rote.
- But much of our work is really rooted in HCI. Human /computer/ interaction. Assumptions are made about what a computer is, where it is, and incidentally what a user does to comply with these basics.
- I contend that mobile is different. Not because it is small. Sometimes, it’s not. But because it is mobile. It is with the user all the time, or at least /more/ of the time, and wherever they are. As we get to the Internet of Things, we’ll have non-mobile devices, but ones that act very differently from any computer we’re used to, and which are so ubiquitous you may be surrounded by computing without touching one. The upshot is that the shortcuts we’ve adopted over time are revealed to be unhelpful discriminatory biases when applied to new systems. I am reiterating this because even if you know all this, it’s hard to think the right way. It takes a conscious effort to remember to have user empathy, and not get stuck into comfortable habits of design, or think only of how you use devices and services.
- Real user centric design requires backing up, approaching problems fresh, really from the user’s point of view, and then considering what is really unique and powerful about the platforms that you are led to.
- (DO NOT READ LIST)Let’s assume that your process leads you to mobile. It does for me a lot—not always, but a lot—as I am hired into mobile-centric projects and teams. Ideally, we let things lead where they may, but outcomes are a bit pre-determined. First…
- Don’t draw. 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, which I and many of us are naturally inclined to do, we 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?
- While the user’s goals are interesting, often the best way to understand that is to answer “what are they using now.” Very often, it’s surprising. It’s not a website, or any a competing product. Often it’s post-it notes on the fridge. Drawers full of labels and manuals. Or even nothing. The photo is from just last week, where I am tested a mobile app to do something (secret) connected with smartphones and trucks. These are their records. There is NO good digital product for the legally-required recordkeeping for their 130 trucks. In the old days we wanted to replace paper with sitting at a computer to solve problems. Now we can more closely emulate the environment, and the overall user context. Ethnography (sitting with the user to understand how they go about their day) is even more important. Find your users.
- To gather data from organizations, as the very first or clarifying steps, I like these sorts of processes (SCREEN). Things like KJ, which has been around forever and which Jared Spool has written a lovely treatise on doing well. It’s about getting information out of organizations and teams. http://www.uie.com/articles/kj_technique/
- I like these not just because it’s an effective data gathering method, or because it’s easy to make device-agnostic and user-centric, but because it’s a collaborative method. Inherently. It is set up to assure that everyone contributes equally. And I can even demonstrate this quickly… but it takes slightly more time than we have. So instead:
- This is another example of a way to gather information. When I have to fall back on a questionnaire, it’s because there’s no way to get everyone in the same room (due to time, cost or a very widely dispersed team). So, I ask these sorts of very, very specific and narrow questions and then coordinate the answers and sort of moderate offline. You should have paper like this already. Grab a pen, and we’re going to fill them out. http://shoobe01.blogspot.com/2012/02/client-questionnaire.html
- But how?Ideally, I’d like everyone to work as a group. We’re going to use a sample project for the other couple of exercises I have, so pick one. Ideally, use a real project someone at the table is working on, but if no one volunteers then use something common and public that everyone can recognize. For your new project, use this sheet to understand it. The rest of the table, ask the questions, and really get on them if the answer is too long, too tactical, too platform specific, or just unclear. Take a few minutes to do that now, and I’ll walk around so grab me or raise your hands if there’s trouble.
- Has anyone heard of “API-First”? I admit it’s new, but I like the concept. Design services, then you don’t have to worry about platforms shifting or having to jump into some new market where 40% of the users are on Windows Phone. You can react quickly because your core product is a generalized service. This is a half step above that, and focuses on user empathy. Which is not just touchy-feely but about recognizing and understanding the significance of user goals and behaviors. The process you draw should be about the user, not the system. 10 MINUTES
- Sketching processes 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. You can do it collaboratively, as a team, like this or by reorganizing post-it notes again. 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.
- If you are wondering why there’s so much focus on drawing and writing, that’s on purpose. I believe very strongly in design being a distinct task, and probably a distinct team. Basically for this reason: There’s no way to sketch an ecosystem in code. You need database developers, API developers, software developers, maybe middleware, and a team for each presentation platform. At least. I know a few people good at several of these. I know no one good at everything. And I want to be clear I come to this not as a random naysayer. I wrote maybe the first CSS used by a Fortune 500. I managed teams of developers. I have done over 150 Agile projects alone. I get every theory. And this is what I believe.
- (SHOW PHONES)Get more phones. Like these. Cheap phones. Slightly broken phones. You can swap SIMs, but WiFi only will do in a pinch. Even if you just LOVE your iPhone, when you find out that 70% of the user base is on Android (or Blackberry), get one, use it, and start building the best experience you can for those people also.
- Try everything at least once. Buy your groceries with your phone. Book an un-taxi. Play augmented reality games. Try different browser, or twitter clients. Get a little in the head of your users. Don’t look down on others, and assume you platform and app choices are simply the best. And if you have to test stuff, boy are you in luck. Responsive site, or multi-platform app? Pull them all out at the same time and check it side by side. Great way to see differences and bugs.
- 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. Or just 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. Pass the phone around the room to show it to clients. Run it by users to test it out. Sure, prototype tools are fine also, and especially simple tools like PopApp or GetLaunch to turn screenshots or sketches into “prototypes.” But get off the computer, and check on real devices as much as possible.
- Now, we’re going to draw an interface for that product you outlined above. For time, we’re skipping the structure and flow, so fake it. And everyone participate. You can all draw competing screens, or assign parts of the process to everyone at the table, or work as little groups, with one person drawing and others suggesting widgets and placement.
- The grid is not a grid. I’ll explain it late tomorrow, but it’s a size guideline for touch interference. Make sure no two targets are inside a box the size of the location. Things in the center of the screen can be closer together than the edges. Yes, there are both iPhone and Android sheets. Trade around to grab what you are familiar with. 20 MINUTES
- Now we’re going to distinctly get into the part where someone will scoff that we’re not working in a prototype tool, or just “sketching in code.” Why bother with documents? Like I said earlier, I’ve come to these conclusions by experience in mixed teams and tasks, and by failing.
- But mostly it’s because there’s no such thing as an ecosystem developer. Or even really a platform agnostic prototyping tool. You have to use tools and methods that give you opportunities to explore, and communicate any behavior, not just what’s on the mobile platform.
- So, this is still out, right? Now, if you didn’t already jump ahead…
- … I want you to fill it out the rest of the way. Annotate the interface and interactions you expect to see. Sketch and describe drag or press-and-hold actions. Annotation can make things easier: Share here is default. It opens an action intent dialog. So, I never need to draw that. Done! START – 10 MINUTES?More chatting… PORE over the drawing. Every feature needs to be described, in as much detail as you can. This is a sketch, but in detailed annotations I include sizes of every element, at device scale (iOS points and sp or dp) and things like color, the time and type of transition for animations, the area that is activated by touch or drag, etc.
- We all know the value of usability research I am sure. But even if we have enough resources and time (and I never seem to) no one has the time to do a usability test weekly. Or daily. You can use heuristic evaluations (or expert reviews) more than a lot of people know. Not just for pre-test validation, but as an everyday checkpoint. And I mean, every day. When you take that break to put the design on your phone, evaluate it. Somewhat formally, but briefly.
- My quickest checklist is much less a list of heuristics than principles: — Does the information architecture (the visible structure of the site or app, and arrangement of items on the page) make sense?— What about errors? Can the user get out of them? Can you eliminate errors from the process?— Throw away the happy path. What if, instead of the home page, users pop into a random page or point in your site or app. Does it even work? Does it make sense?— Are you lying? Does the structure or language obscure the true organization, data, or structure of the system or process?http://www.kcstartupvillage.org/blog/2013/10/improving-user-experience-easy-cleaning-room/#sthash.GEUzFWBj.ljCFuGUz.dpuf
- The last worksheet I have at the table is a longer list of heuristics I evaluate for when I have the time. Take one of these lists, again preferably as a group, and evaluate… … your neighbor’s design. You can either pass along, or actually go over and watch the evaluation happen. Yes, not everything on there will apply to every design. That’s fine, just skip them. 10-15 MINUTES… WHAT IS LEFT?
- I am constantly changing the tools I use, and this is just a short sampling. Let it be a guide to find the right tool, and approach those you use in a new way, to find the right answers from them all.
- And certainly, feel free to ask me questions as well.