The Trouble With All Those Boxes: Designing for ecosystems and people instead of screens and pages
•Transferir como PPTX, PDF•
1 gostou•1,143 visualizações
As we get information about how people use mobile devices it’s becoming clear that bad design is not just something that turns off us nerds, but turns away your users as well. I will outline a set of principles and practices to design and execute products in a systematized way, while preserving individualized interactions, and beautiful interfaces, as well as sticking to your schedule and budget. The slides don't make a lot of sense so be SURE to read the notes, which are included. Presented 19 April 2013 at MMConf, in Krakow
Recomendados
Mais conteúdo relacionado
Mais de Steven Hoober
Mais de Steven Hoober (20)
Último
Último (20)
The Trouble With All Those Boxes: Designing for ecosystems and people instead of screens and pages
- 1. The Trouble With All Those Boxes Designing for ecosystems and people instead of screens and pages @shoobe01 1
- 2. 2
- 3. 3
- 4. 4
- 5. 5
- 6. 6
- 7. 7
- 8. ―I'm as interested in "channels" as a thing when designing ecosystems as I am in pages when reading a book.‖ – Andrea Resmini @resmini 8
- 9. 9
- 10. 10
- 11. 11
- 12. 12
- 13. ―What we’re doing is trying to translocate information, and all the machine does is impair that process. Possibly infinitely. You have a choice over where it goes, and that’s it.‖ – Martin Geddes @hypervoice 13
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. • Design for Every Screen • Design for Failure • Mobile is More 18
- 19. • Design for Every Screen • Design for Failure • Mobile is More 19
- 20. 20
- 21. 21
- 22. 22
- 23. 23
- 24. • Design for Every Screen • Design for Failure • Mobile is More 24
- 25. 25
- 26. ―when these subsystems are combined into larger systems, we enter the world of non-linear dynamics, complex interactions, chaotic behavior — and often, disastrous non-resilience...‖ – Michael Mehaffy tectics.com 26
- 27. 27
- 28. • Design for Every Screen • Design for Failure • Mobile is More 28
- 29. 29
- 30. Wrong 30
- 31. 31
- 32. ―…inequality is where the opportunities/challenges for design really are.‖ – Andrea Resmini @resmini 32
- 33. 33
- 34. 34
- 35. 35
- 36. 36
- 37. 37
- 38. 38
- 39. 39
- 40. 40
- 41. 41
- 42. 42
- 43. Lost? Confused? Disagree? 43
- 44. Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 0455 (not this week!) @shoobe01 shoobe01 on: www.4ourth.com 44
- 45. 45
- 46. 46
Notas do Editor
- First, I want to say that as much as I write and present and may sound like I am entirely sure of my ideas, I don’t actually like to lecture. So, don’t just wait for the end. If I say something clearly wrong or confusing, stop and ask me about it. If we run out of time, or you are shy, please corner me at lunch, or tweet at me, email me, or whatever and we’ll talk. Before I get into it, I also want to know who I am talking to. How many people here consider themselves designers? I mean as opposed to developers, so if you are an IA or something, raise your hand.
- …We all design-- and I mean technical design as well as UXdesign -- based on boxes. We love our boxes.
- Whether they are big, metal boxes moved by forklift or the little plastic boxes in our pockets, we tend to forget that they are connected, shared and used to do work in the real world.
- And because it’s all about the computer, we forget to “think like a human,” as Jeremy Olson said yesterday. We design features, systems, tasks and content that fit into little boxes. Into computer screens, and flowcharts that show paths between little boxes of information. We design processes that progress in predictable, linear ways, inside that system, and present information in little boxes of content, on glowing screens.
- And yes, we call these “systems,” but we don’t really mean it. Systems are inter-related, multi-part, and generalized. Systems are toolboxes with drawers full of capabilities. When most of us are building a website or application, we’re build tools. Tools do one thing, in more or less one way.
- There have been plenty of complex information and computational systems for a long time, but networks changed everything. If we think about networks, we consider them as connections between machines, delivering packets (more boxes on the diagrams) of data between them.
- But that’s not quite right. Networks do not connect computers. Networks don’t even exist, really. And thinking of networks as packet delivery mechanisms doesn’t really help. Networks are instead just ways of making our computers bigger. Of making the world be one, large, distributed computing and storage system. You don’t use the cloud, you are part of it.
- When you think like this, you should start noticing the boundaries between channels or device classes start breaking down.
- Think about that. How would you design your product if it wasn’t for an iPhone screen, but for the whole world? I am not kidding, or weaving crazy tales. How does, say, Facebook work? Or Twitter?
- They work on the Web, both mobile and desktop. On apps and widgets on handsets, and computers. On smart TVs, and Twitter especially is famously over SMS. In email. Don’t underestimate the power of email. Via push messaging platforms. Via APIs. As services. These, and others, are services that can be used by their owners, or in some cases by anyone, to offer the product in all sorts of ways. In ways that could not be predicted when they started. But they had one key winning attribute: that theydon’t need to predict in detail how it will be used, on what platform. They can just build servicesso we can build interfaces (or let others) to any platform, any time they want to. Yes, that’s a kiosk. And the featurephone? Last time someone could calculate the numbers (they are hidden now) 82 million regular users of the J2ME app on FEATUREPHONES. Less than half the Android or iOS platform, but that’s a lot of people; don’t you wish you had a spare 80 million users? It is a lot of opportunity when 80% of the world is still on featurephones.
- Lest you think everyone big and successful is doing it right and not missing a beat, let me use a counter-example. Who here uses Flickr? HANDS I do. A lot, and for years, not just since everyone supposedly gave up on Instagram. I don’t much use other services because I have 20,000 tagged and organized images there.I am invested. But, I don’t use it as much from mobile because it fails me. When I click a link in an email, or Google search, I most often get… the desktop website inside the browser. I am not even so worried about them not having a mobile site. They need a custom URI. They need to launch the app they are so proud of every time someone thinks “Flickr” on mobile. They are thinking of boxes, instead of systems and have checked the box for “mobile app” without thinking about the whole ecosystem or how we use this stuff.
- Like here, they are chasing the competition onboxes. Check the box that says “we offer filters!” Why? Does this meet some specific need of THEIR users? And why is it only on the mobile app? It’s not on the desktop, so is clearly not a service but a little widget residing locally in the apps. I think they even have different filters between the iOS and Android apps.
- Some people will go even further. Our happy glowing screens on all our beloved devices are actually getting in the way. I’ve been told by someone very clever about networks “what we’re doing is trying to translocate information, and all the machine does is impair that process. Possibly infinitely. You have a choice over where it goes, and that’s it.” Networks can be thought of only as delay-engines, and all our access platforms (our phones, computers and web browsers) as methods to divorce us further from the innate truth and meaning of the information.
- It doesn’t mean you don’t do the best possible job when designing interfaces. But first, you allow arbitrary access, so there’s customer choice; they get to pick the platform they are most comfortable with.And you need to push to platforms that fulfill these needs. Any platform. Screen-free platforms, like this are critical not just for special classes of uses, but what I took from Robin Christopher’s talk yesterday is that all of us can use these technologies. We get “temporarily disabled.” And users become exposed to your information from several sources, so it becomes almost ambient. Think about where and how your information can do the most good.
- We should never expose the edges of the system like this, much less require the user to press a button to try again. We need to design and build with an understanding of delay, and difficulty. Both technical delays and because of our lives. Users get interrupted, and switch platforms. Networks fail, and stall, and delay. We have to cache data, allow working offline, build for multi-channel, multi-device use cases. We have to and automatically synch and not cause errors when there are mismatches. We should resume, and synch and encourage sharing so users can resume tasks when they get home, or get to work and sit down.
- Ifyou don’t get what I mean, or why, let’s take a specific case, maps. This is not about how Apple tried to get me lost on the Polish A roads. You might need maps when you are far into the boonies. Or you want to know where you are going next while in a tunnel, in one of the no-network area on an underground subway. A month or two ago, I used an iPhone on my bike mount driving around San Francisco, but didn’t bother to put in a SIM. I have lots of phones, most don’t have plans so I carried another one with me as well. I just cached the maps and used GPS alone. Implementations vary, in ways that are useful to illustrate this: Google maps on iOS does… nothing. If you are off network, you get a useless blur. Google maps on Android does a better job of having a “basemap,” a permanently cached global map, but you can maybe find half a dozen towns per state, and maybe none per country in sub-saharan Africa. They do have a service to manually cache areas, but you have to plan ahead. And can only save so many of these. iOS Maps has, despite other flaws, probably the best overall solution: It automatically caches. If you have looked at the area lately, it’ll keep it stored offline. So if you plan your trip, then go there soon enough it’s saved.
- If you do any of this adaptive stuff wrong, or don’t do it at all, users will notice. I like to use map caching as an easy-to-see example, but generally, users are intolerant of bad systems. There is an increasing body of actual research that everyday users do not use, for example, tablet apps that are obviously just phone apps stretched to fit the screen (photo). Or, take Facebook’s hybrid app failure. This was not a nerdy developer and designer issue, but everyday people rejected a major service and stopped using the app. We know this because they admitted to a sustained 4-fold increase in use almost overnight, when they launched the first native app. Do not dismiss these concerns as nerdy, niggling disagreements. We’re all nerds now, and your users care.
- Okay…We already know how to do all this. And I suspect everything else I’ll tell you in the next few slides you know also. Connecting the two is what is key. Several others in the past two days have, as I read it, been talking about creating cultures that encourage building great products. This is the same sort of thing. There are a lot of principles and practices and concepts and examples and pithy phrases I could give you. I do change my mind and modify this periodically, but today I think if we could all get to a common understanding of these three points, we could do a lot better for our products, our clients and our users.
- Design for Every Screen is my attempt at a clever catchphrase. Of course, I don’t just mean screens, but “platforms” somehowsounds less great and they are sorta not real either so that would be worth arguing also. It’s essentially whatJakob Nielsen calls the “Transmedia User Experience,“ which is even less catchy, so I don’t feel so bad. This is also my counter to things like how “Mobile First,” which isn’t bad, butis too often misinterpreted to meana different excusive choice. It also meshes nicelywith product development and implementation processes that I’ve seen have good results. You can also think of it as designing agnostic of any interface (maybe even with NO interface), or designing for services.
- That means designing for people. I do work for big dumb For legacy systems and services and to integrate with or build on existing products. It means when you do the discovery work you already do, like seeing how people shop for greeting cards (photo) you don’t just take it as input but turn that directly into task flows and architectures. You don’t make assumptions about presentation layer, platform or technology, but you let the user needs (and business needs, and so on) but let those evolve organically from the design process.
- Build concepts that talk about services, data, sensors, networks and users. Not screens. Don’t just put your goals and objectives on the wall, or on the first page of the desk, but bake them into the diagram.
- Storyboard. When you settleon platforms, sketch them out as part of the user task. All the way from boring old things like email, SMS (photo) or notifications. Think about what happens outside the screen. Show what happens outside the screen.
- Never let project constraints keep you from conceiving of future interfaces, to make sure the architecture, the whole solution, is future friendly. I am sure Josh will talk about this in a couple hours, but Patrick Broman was right yesterday when he said “Never say never.”No, this particular smart TV widget didn’t launch yet. But it’s on the roadmap, and everyone from the CEO to the data architects knows it is.
- …Who here has heard of Resilience Design, as an engineering and security practice? It is used to keep services like Google, Facebook, Etsy, Flickr, Yahoo, or Amazon online. At a deep engineering level they follow practices and procedures to assure their systems are not brittle, and avoid failure or fail gracefully and can be fixed easily. Well, we rarely need to design end-user systems for true catastrophes, but for any digital product there are many failure modes we simply are not accounting for. And we really should.
- Resilience is usually defined as the ability of a system to absorb disruptions without tipping over to a new kind of order. A building when exposed to too much lateral ground movement settles into a state of “pile of rubble on the ground” unless you design it to resist this disruption adequately. Weapproach all design of technical systems from the engineering perspective, and assume we can codify the process, so predict failure points. We can’t. Our systems are embedded in other technical systems, embedded into complex systems, like the user carrying it around, who may be subject to rain, and traffic delays, and screaming babies.
- Resilient structures are designed to be interconnected networks, instead of hierarchies. This might start sounding familiar. We need to design our systems to work with users’ messy lives. To account for arbitrary complexity, chaos, and failure.
- Failure means anything you didn’t predict. It means planning on users missing the target on their small touchscreen. So it’s not catastrophic, and maybe so the whole system works better anyway. It means you never say the word “happy path” again, much less design for it. Users do not enter your site (or app) from the “home page” anymore. Stop designing like that. (This is a site I run. These are real numbers.) I don’t pay much attention to the way the home page works anymore.
- Mobile is More. Not less.
- The standard line, which I am /still hearing people say/ is that mobile is smaller and less capable, so you must “ruthlessly cut” features, content, etc. This means, in comparison to desktop. A tablet is in between, so you cut half the features, I guess.
- Wrong
- But as much as we all like mobile, we have to admit every device is different, and every device is good in its own way. For scale, look up here. The TV is almost ambient, the computer might as well be on a desk, as my lap is an ad hoc workstation, and the handset is held up, closer to the user. Those differences almost disappear based on the way devices are used.
- Not disappear in the sense of merge, but because the capabilities and interactions are matched to the way they are used. Embrace these differences.
- These differences in device capabilities are great. This is stuff that gets me excited! Mobiles are in no way like desktop computers. And they are not like cars. And so on. But in ways more than the size of the screen. Or input method. Most of all due to sensors as we heard about yesterday. And also critically more seamless access to the features most computers have like connectivity. Data entry, for example, can be made trivial:by removing it. Since the device is reliably connected, and full of sensors, it canalready knowwhat the user wants.
- I know this isn’t a mobile phone, but it’s a great example that’s easy to see and understand, and is a good way to talk about how no-interface and pre-emptive tasking is probably the future anyway. It’s a hand-washing station. You press a button for water, then a button for soap, then a button for water, then a button for air, then dry your hands on your shirt. They each come out different places, so you move your hands to different positions. Which is not enough to turn it you. You really do have to press a button. Wet, soapy, etc. In this day and age. Unsanitary? Mostly, un-necessary. Sensors are (seriously) cheaper than buttons and can make the experience a LOT better.
- Back to one of the glass rectangles we’re all here to talk about. Say you are building astore locator functionas part of your tablet app. You don’t ask users totype their location in, do you? Because the device knows already. I don’t even put in “Search” buttons for things like this (not that I claim to have built this Square wallet app I am showing off here), and at least for maps, most designers don’t. When you open the feature, you get a map.
- Even when you allow typing, you do it intelligently. You think about what users know, care about and tolerate. This IS something I am working on (it’s not launched just yet so don’t complain about the details; there are probably open bugs on them). It automatically detects location and populates it. Note here it’s only got coarse location so we don’t use the centroid of the area and call it a street address. We use the data we have correctly, within the constraints we know. But it also lets the user type. Not lat/long figures, not precise addresses. Who knows the postal code when visiting a store? Nope, we use the Google Places API which lets you type in place names. Stores, landmarks, stuff that people think of the way they think about it. Yes, it offers autocomplete options, so the user can type just a few characters sometimes, and tap to pick from the list. And this didn’t even muddle our data structure as any result the user accepts turns into a geocoded address in the location field and a store name in a field elsewhere.
- Several things got released broadly yesterday, but I am not going to talk about the many and massive issues with Facebook Home, or trends in weather apps. But the update to the Facebook app itself also got some tweaks, and one got comments from UX people I follow that made me crazy. “Yea! Now Facebook will have a way to reveal the password.” Are you kidding? Its trite but true that text entry is hard. This should be “Finally, someone at Facebook almost got to the right interface design. There’s no such thing as shoulder surfing, and text entry of arbitrarily-complex things like passwords is almost impossible when masked. Stop doing that. Optionally revealing isn’t good enough.
- We have to design, each platform, every platform, to take advantage of the features inherent to it, and the unique environment, and user expectations.Sharing is another. Not the concept, but the implementation where you just press “Share” is brilliantly good stuff. It appeals to the way people cognitively address tasks like this. If you are building email forms into your desktop website, that’s correct. But for mobile web and apps, that’s wrong. You link to installed applications because that’s the expectation and method of operation of mobiles.
- Do whatever is right for whatever system you and your users work with.TV, and kiosks and telematics and so on will all have their good points. And these are ALL here. Millions of Smart TV downloads have already been sold. You’ve all seen you can now develop for cars. Mobile handsets and tablets are, relatively, easy to understand. You have to stop thinking of mobiles as tiny, crippled desktops, with weird touch interfaces that mean you can’t use hover states. You need to embrace the network connectivity, the portability, the presence, the sensors, the intelligence, the integration, the personalization.
- Because I don’t need to remind anyone, that while we carry these little boxes with us everywhere —and connected information system pervade every one corner of our lives…
- …you cannot put people into boxes…
- … and need to consider how this connectivity and interactivity affects everyday people. We need to consider what we design and build to be a system, embedded in other systems, embedded in a mesh of systems that make up our individual but interconnected lives.
- Time for Q&A? If not…
- …if not, or your question didn’t get answered, or I dodged it, etc. ask me afterwards or contact me any way you can. If you miss these addresses, just Google my name and you’ll find me. Like everyone else I also have free stickers and O’Reilly gives me discount cards to hand out so if you want to buy my pattern book, just ask for one.
- APPENDIX: Slides that didn’t make it due to time and flow. But I might use as examples during Q&A. So maybe you do support multiple platforms. You have a couple of apps, and a responsive website. But tell me, do you dread the thought of building a specific Android tablet app. Or of Windows Phone (or God forbid, Blackberry 10) taking off, because you’ll have to support /another/ platform? I think today’s announcement from RIM is a great point: They launched their BlackBerry Enterprise Service 10, to go with BB10. But unlike moves from people like MS with their Windows cutover, this management tool works with existing BlackBerry OS devices. And with iOS. And with Android. Services, multi-platform services, are not just the future. They are reality today.
- APPENDIX: Slides that didn’t make it due to time and flow. But I might use as examples during Q&A. If this multi-platform stuff worries you, or if you are someone who gripes about fragmentation, you are doing it wrong. First, we’re UX designers. The users are making choices of these platforms, and all these device sizes. They are not being tricked into it, they are not cheapskates no matter what Gizmodo says. You must to respect user choice of device and platform. Use analytics and not opinion to make your decisions. Implementation-wise, another platform is a simple, easy extension to your core /service/. I’ll say it again: most of us should not be designing and building apps or sites, but services that happen to have a variety of front ends. How easy is it to extend? I know people who have launched on another platform by adding one person to the team. One Android developer, some designers you already had on staff, and literally weeks later there’s a beta version to play with. I know people who have had alpha ports to a new platform within ONE DAY.