Designing for ecosystems and people instead of screens and pages
•Als PPTX, PDF herunterladen•
8 gefällt mir•1,362 views
How successful strategies involve focusing on and embracing complexity, fragmentation and unpredictability of the way users employ mobile digital and especially mobile systems. BE SURE TO READ THE NOTES attached to each slide. The slides themselves are mostly pretty pictures, so won't make a lot of sense. Presented 23 January 2013 at an IXDA Silicon Valley and BayCHI event hosted by Yahoo! in Sunnyvale, CA.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (11)
Ähnlich wie Designing for ecosystems and people instead of screens and pages
Ähnlich wie Designing for ecosystems and people instead of screens and pages (20)
Mehr von Steven Hoober
Mehr von Steven Hoober (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
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 @IxDA @BayCHI 1
- 2. 2
- 3. 3
- 4. 4
- 5. 5
- 6. 6
- 7. 7
- 8. 8
- 9. 9
- 10. 10
- 11. 11
- 12. ―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 12
- 13. 13
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. 18
- 19. • Design for Every Screen • Design for Failure • Mobile is More 19
- 20. • Design for Every Screen • Design for Failure • Mobile is More 20
- 21. 21
- 22. 22
- 23. 23
- 24. 24
- 25. 25
- 26. 26
- 27. 27
- 28. 28
- 29. 29
- 30. • Design for Every Screen • Design for Failure • Mobile is More 30
- 31. 31
- 32. ―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 32
- 33. 33
- 34. 34
- 35. 35
- 36. 36
- 37. 37
- 38. 38
- 39. • Design for Every Screen • Design for Failure • Mobile is More 39
- 40. 40
- 41. Wrong 41
- 42. 42
- 43. 43
- 44. 44
- 45. 45
- 46. 46
- 47. 47
- 48. 48
- 49. 49
- 50. 50
- 51. 51
- 52. Lost? Confused? Disagree? 52
- 53. Giveaway time! 53
- 54. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 54
- 55. Let’s try this 55
- 56. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 56
Hinweis der Redaktion
- Thanks,Pabini… Make sure you put your business card (or a post-it, or something with your name on it) in the drawing (Basket? Bucket?) for some of the fabulous prizes.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, please raise your hand, interrupt as you need. No need to wait for the end of the session. I’ll warn you that if you even just look too quizzically at me, I may call on you to make sure I haven’t overstepped, or mis-stated something.
- …We make designs -- and I mean technical design as well as UXdesign -- based on boxes. We love our boxes [post its].
- 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 the user. 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.
- 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. 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), and 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? 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 per app.
- 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, even screen-free platforms, that fulfill these needs. Users become exposed to your information from several sources, and it becomes almost ambient. Think about where and how your information can do the most good.
- And we design with an understanding of delay and difficulty. Both technical 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. We should never expose the edges of the system like this (image).
- If you don’t get what I mean, or why, let’s take a specific case, maps. 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 BART. The other day, I used an iPhone on my bike mount driving around the city, but didn’t bother to put in a SIM (I have lots of phones, most don’t have plans) because I could cache the maps and just use GPS. 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 this sort of thing wrong, or don’t do it at all, users will notice. I am using 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.
- 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.
- Anyway, 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.
- So… instead of just telling you it can be done, how about some specific tactics? There are a lot of principles and practices and concepts and examples and pithy phrases I could give you. And I change my mind and modify this periodically, but today I think if we could all address 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. This is also my counter to things like how “Mobile First,” which isn’t bad, butis too often misinterpreted as a 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, or designing for services.
- I can talk about this for hours, and I have. But relatively briefly… This is all based on principles you know and say, from UCD, Service Design, etc. First, you understand the problem. Ideally, get in a room with product owners and do research and so on. Find out about current processes, legacy systems, the ways the physical channel works if that exists. Don’t make assumptions about presentation layer. At all. Try not to make assumptions about anything. Here, as part of a client workshop for project kickoff, our design team is in a store with the client team from Hallmark.
- Concept the system, independent of any interfaces or technologies (except maybe legacy datastores, business processes and the like). Note here is a typical of the sort of thing I encourage. Don’t start with drawing screens. Design the overall experience, the complete process, and how the technical or procedural system touches end users.Here: users have a discovery method, and a transaction method, so there’s two pictures of people. And then the UI and functional facets are shown around it, with links to show the association. I even included the merchant as a person; not just the way he transacts with the consumer, but because he has his own management portal. If it helps to storyboard or use other tools, do so in order to keep in mind the context of the user even more.
- This sort of diagram works. Here’s a hand-drawn one for MyLowe’s (image). The people here are not the deisgn team. Be sure to share. Put your principles, personas, concepts in front of the business owners, the implementation team, legal or whoever might cause a hangup. Ideally, put it on a wall. Or several walls. Bring them over (as here) to walk them through it all.
- As much as that sort of diagramming works, you are going to have to draw screens. They will be speculative and you throw them away, but sometime someone will demand to know “what it will look like.” We’ll set aside issues of interfaceless experiences for now. Make sure you draw the interface and interaction on several platforms for each one. Not just to explain this principle others, but to assure you are not getting caught in any device-specific feature traps. If worried, a simple check to assure you aren’t doing this -- that the core of the concept document is platform agnostic – I to add another platform…
- … a widget for smart TV, say. While drawing it, you are checking to see that it doesn’t break your core concept. If not, then you are designing for users and systems and services instead of screens and pages. This can be a natural part of the process as you get used to designing like this again. When you build example interfaces, start with one and add others until you expose weaknesses, then fix the design.
- I also like to show comps or mockups in context. Sometimes politics and organizations get in the way, but at least at the concept level it’s really useful to get permanent, irrevocable buy-in. And a successful way for me is to make the high-fidelity mockups inside handset frames, as part of an abbreviated process, and with a sketch of the user’s context or whatever other system or over-riding concern is at play.Here, the project is about getting people their service on the go, so a street scene in the background was enough to communicate this. The Play store icon is also key, as discovery was a concern based on the type of user and the region the project is based in.
- Some people get antsy about spending lots of time on concepts, but it goes back to the whole value of UX work. If we know what we’re doing, and we know we’re doing the right thing, implementation is less error prone. I find the same can be observed with multi-step design processes; each progressive step is easier and less error prone. Now, it’s time to specify the complete process, flow and to a certain degree the interactions (the little right arrow), for ALL the platforms at the same time, in the same diagram. I call this a blueprint, partly just to have a name to differentiate it from what we normally call wireframes, IA diagrams, sitemaps and so on. Note that this is a process flow really, not a sitemap. Thinking systematically means these are more often than not states, instead of pages in the traditional, boring old web sense.
- The you branch the design. Just like code is branched to a specific featureset, platform, etc. you take the core design, once all approved, and build specific UI specifications off it. You should be able to almost just cross out the parts of the blueprint that don’t apply to each platform. The camera feature on the mobile? Well, that doesn’t work on desktop web, so “X.” We decided to make registration only on the web, so the app gets that X’d out, and a link to the mobile web instead. Variations are fine also. The end result is similar to anything you build today, and will be specific to the platform, but it ties back to the blueprint, the concepts and the principles you developed along the way.
- Then build for each one in turn. We can talk further about implementation strategies if anyone wants to, but if you aren’t going to build lots of platforms today, that’s fine. You still need to plan for the future. Consider all this a target design, and execute to that over time. This chart is what I always suggest as a way to execute for multiple platforms, and integrate good UX work with it. I’ve got other presentations around it, but it’s here to point out these are doable, not just theoretical. And it’s not even so radical you have to take special training; it’s a natural way to balance resource constraints with business needs and gain efficiencies.
- …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. We tend to approach all design of technical systems from the engineering perspective, and assume we can codify the process, so predict failure points. But we can’t. Forget arbitrary complexity, which is interesting. No, I mean that a system we design for say a mobile phone is embedded into other systems (the device OS), which are embedded in yet more 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.
- A simple one I have already mentioned, is that too many mobile apps are incapable of working, or at least working well, when the network connection drops, even momentarily. Local storage and robust caching can make these work a lot better. Here’s a catalog lookup app I designed that simply has to work offline as real live use cases are deep in jungles of third world countries, and down mineshafts. But the principle is easy and important to follow for lots of products. See the cloud and the two silos? One of those is local, and we have synch service. And yes, there can be limits. For a consumer app I could rely on regular network updates, but for this it might be on a MID that is rarely connected, so I had to add more robust warnings, or errors I guess, to make sure they don’t run out of storage. It’s a big catalog.
- More complex, and more user-centric, is to 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.This [image] is a site I run, something you haven’t seen as it’s one of my few hobbies that has zero to do with my day job. It gets almost 50,000 visits a month. And 38 of those this last month landed on the home page. It’s very well indexed, so assuming the home page matters is not a recipe for success.
- We are starting to see this trend, especially in things like messaging apps. You wouldn’t expect to open your Twitter client and get a home page with big button options to read tweets, compose new, etc. That would be stupid. You get information, immediately. Of course. If you don’t do this in your product, think about why not? Is there a reason, or is it just inertia?
- Another way to say this is to design to be error free. Sometimes you can’t avoid entry so forms are your pitfall still. Well, here is a way you can design to avoid and prevent errors. The user cannot submit the form until it’s filled in, correctly. And we tell them this is what is needed, then tell them the next steps.
- If you can’t be error-free, flip the problem on your head. Embrace your problems and literally turn them into solutions. Let me walk you through two examples of something I was working on just last week.We don’t assume that everyone is entering the site through the home page, so they need to be aware of where they are at any time; wayfinding is an exercise in designing for unusual cases. These breadcrumb-like titles expose the location to the user. Ideally, we’d also flatten the architecture, but that’s not always possible when working with existing organizations.
- As another part of the same product, I need to put both Share and Follow functions on each page. I think they need to be adjacent to the title for good ID/IA reasons, but that gets really tight so even if I don’t have an icon for Facebook, Twitter, LinkedIn and YouTube separately.So I embraced errors and let the icons be too close together; they both are one button that goes the same place…… and then the user chooses the function from one of the two categories on a very simple list page.
- 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
- If you are a desktop web designer (or developer) and cannot stretch your mind much further than that, you will say that:Mobiles have small screens.Mobiles are hard to type on.And then you yell about all the fragmentation making your job hard. But each device is different. 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.
- And yet, more differences emerge. But good ones that make the answer more useful. Because of sensors, and more seamless access to the features most computers have.Data entry, for example, can be made trivial, by removing un-needed entry. Since the device is reliably connected, and full of sensors, already know what the user wants.
- Say you are building alocator function for your product. You don’t ask them to type 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.
- Oh, sure, you can also offer typing as an alternative (I did design this one). Because it’s easy to add that feature in with little or no space. Because we don’t remove features from mobiles. We just put in the right features.
- The device is full of other features you can leverage to make it easier to use, and easier to develop for. One of my favorite examples is email. On desktop web it’s common -- a truly best practice --to build web forms and submit from your site. It’s the opposite on mobile, where the expectation and best experience is to go out to the device email client.
- There are much, much cooler features as well. What is the device camera used for now? Scanning checks, reading currency values, reading and translating languages, AR for finding things and driving safety, scanning codes and finding products. Up here (on the screen) is an app that checks your pulse by using the flash and camera. Really. Here is where I wrap back around to the first point, the Design for Every Screen process. If you think about things from ANY one platform, you miss platform (or class-of-platform) specific features. What features can you improve like this?
- I can say this about any platform really. 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.
- And of course I hope 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 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.
- Wrapups are boring. I am not going to make you watch me read a bullet list, so let’s go straight to questions. Who disagrees with something I said? Or didn’t follow something I said? Or wants more detail on one of the many topics I skimmed over?
- Before we take a break, let me give away a few things. T-shirts (3?), note they have sizes on the tape as well as the choice of color, but first-come first-served. (If it really won’t fit, tell me and I’ll mail the right size to you). Touch template. For inspecting target sizes and sketching designs. Book double package deal: My Designing Mobile Interfaces and the newer of the two editions of Jennifer Tidwell’s Designing Interfaces. No, you only get the dead tree version, as O’Reilly doesn’t know how to give away digital copies.
- Thanks very much…
- Read the handout…
- Thanks very much…
- EMPTY PAGE!