Designing mobile and IoT experiences
•Download as PPTX, PDF•
3 likes•3,834 views
Part of a workshop (you really had to be there) at TechJobsLA on 5 April 2014.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
Similar to Designing mobile and IoT experiences
Similar to Designing mobile and IoT experiences (20)
More from Steven Hoober
More from Steven Hoober (20)
Recently uploaded
Recently uploaded (20)
Designing mobile and IoT experiences
- 1. 1 @shoobe01 @techjobslafair Physical, Digital, Human Designing experiences for mobile and the internet of things
- 2. 2
- 3. 33
- 4. 44
- 5. 5
- 6. 66
- 7. 7
- 8. 88
- 9. 99
- 10. 1010 People
- 11. 1111
- 13. 13 Design high points: • First, don’t draw • Gather, understand • Ecosystems first • Hold, look, tap, connect • Annotate, describe, understand • Evaluate, and validate
- 14. 14 What are we going to build today?
- 16. 16 KJ (Post-It®) Process: • Determine focus questions • Get in a room • Answer questions • Put up answers • Group answers, label groups • Vote on most important groups
- 17. 17 Focus Questions: • What is the product? • What is it’s one main purpose? • What one problem does it solve? • Who will use the product?
- 18. 18
- 19. 19 Learn what you know.
- 20. 20 KJ (Post-It®) Exercise: • “What one problem does it solve?” • Put up answers • Group answers (draw a circle) • Label groups (write the label) • Pick the top three (at most) groups
- 21. 21 OKR
- 22. 22 Objectives and key results.
- 26. 2626
- 29. 29
- 30. 303030
- 31. 31
- 32. 32 Hold, look, tap, connect.
- 33. 3333
- 34. 3434
- 35. 3535
- 36. 36
- 37. 3737
- 38. 38
- 39. 39
- 40. 40 How bad can it be?
- 41. 41
- 42. 42 Cut it apart.
- 44. 44 There is always UI.
- 45. 45
- 46. 46 Validate.
- 47. 47
- 48. 48 Thing
- 49. 49
- 50. 50 Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com
- 51. 51 Embrace failure and complexity.
- 52. 52
- 53. 53 There is no happy path.
- 54. 54
Editor's Notes
- If you have been to other workshops here, you should understand that 2.5 isn’t really enough time. We’ll only have time to simulate exercises that take hours or days to do. So, I’ll talk a bit, you guys will work a bit, and then I will interrupt you just as it gets interesting, talk to you 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 have arranged it so there’s no absolutely critical last lecture. If we run out of time, so be it. We’ll get through what we can as I want you to try some of this stuff yourself. … A couple years ago, this…
- … is what everyone meant when they said “ecosystem.” But that was a passing fad. It’s never been really true, and Apple certainly didn’t invent the ecosystem.
- We've always been about building ecosystems. Your website has password reset emails, lots of people like me have been offering the website on mobile handsets for over 15 years. How about ATMs?Everything is an ecosystem, and good designers know this. Newspapers and magazines are designed not just to be readable, but to be appealing to the newsstand. And, to have room for mailing labels for home delivery.
- But as always happens, new technology gives us an excuse to think about it, or make our clients and bosses pay us to design for ecosystems.This isn’t even future. There are sensors all over, right now. Mostly industrial, with the cable or power company knowing what is going on, and cities monitoring roads.
- And the sensors are getting smaller all the time, and use so little power the batteries don’t need to be changed or charged for months or years, we’re on the cusp of sensorizing and connecting practically everything.
- And that will include sensorizing you. Right now, smart watches like this [pebble] are deliberate, or even more about pushing data to you.
- But these sorts of things are coming for real. Devices that monitor, share, send information about you directly back to somewhere.
- You know this…
- … sorry, this… and this [Pebble] and this [MFV dongle] are bringing us into a world of ubiquitous computing without our noticing it. Except one part is missing from most discussions of building ecosystems.
- The usual problem. We’re building great technical solutions, but it’s not clear who wants them. They are not always easy to use. Stickiness of most wearables is low—people are buying them, then leaving them in drawers after a few weeks.We have multi-screen solutions, but which only work on one platform so you have to have an iPhone, or Android, only. They store data, but in a custom format, and you can’t tell what they know about you.
- And this is what I want to talk about. Design for people. For the way your users, and your business or client, works. To tie REAL real-world thinking into your design of products that work on every screen. 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, to solve problems with technology, or think only of how you and your friends will 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. It is pretty much platform-agnostic, and today with all these devices around us, we’re beginning to be freed from constraints of platforms. We are on the cusp of being able to assume the technology exists to do what we need, and we can approach this from the real-world point of view, from the user and business perspective alone.
- Things change, but keeping it simple and for now this is a good set of touchpoints to hit on to make sure you are designing for users, and for use on every platform and interface needed. Today, we’ll treat it as a process, and step through it one by one, but many of the steps are done over and over, repeatedly, or constantly.
- This is a workshop. We’re going to do actual hands-on work, to start the design of a digital/physical product of some sort. And we’re going to do it by teams. BREAK UP BY TEAMS. 5-6 ON A TEAM. PM/PO + DEV + UX + ??? WRITERS? VIZD?Instead of giving you something, I want you to come up with the product we’re going to design. If you are working on one, tell your team about it. If not, or you /really/ cannot share it, then everyone throw out ideas. Remember, you can just hate your smartwatch or smart thermostat and have a better idea. We can explore existing niches. Do that now. Give an elevator pitch, no more than about 30 seconds, of your product idea. More than one is fine, then the team votes.
- What did you do while deciding on your projects? One of you talked, and the others listened. You asked questions, I hope. You had a conversation, but you didn’t really spend time designing. You didn’t draw (I hope???). Keep doing this. Even when you have a week, instead of two minutes, don’t get ahead of yourself. Listen, ask, listen more. Research, read, analyze. I came to this not from some philosophical understanding, but from failing in the distant past. I am one of those “genius designers” (though I hate that term) who did really well actually interrupting explanations and coming up with solutions on the whiteboard. But, when I stop, listen, and think, I always come up with better solutions. I have done both ways at places with robust success measures. It doesn’t just make you more friendly and popular, but yields better outcomes.
- If you get a team together who have been working on similar products, or have been talking to customers on the first or 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. And, quickly. Ideally, we have a couple hours, but you can do something in a few minutes. Which is all the time we have.
- These are some questions I like to ask, though I don’t always find them by this process. If some like “what is the product” seem simple, I have never asked this of a team — even a team three years into a project — without getting multiple answers. You have to know what you are working on, and make sure everyone is on the same page.
- Incidentally, you can gather this without getting everyone in the room. Send out emails, internet surveys, or get people on calls. http://shoobe01.blogspot.com/2012/02/client-questionnaire.html
- But we’re going to do it live. And we’ll shorten it. Let’s just answer one question. What ONE problem does it solve. Everyone write that answer on a post-it, and put it on the whiteboard. Now I said ONE, but I mean one per Post-It. Have more ideas? Write two. Or five, or fifteen answers. That’s fine. Start doing those now, as I keep talking at you. Assume that you are the project team, and everyone’s answers are valid, so whatever you got from the elevator pitch earlier is what the project is. 20 MINUTES IF POSSIBLE.
- Pick a moderator to make sure you are doing the exercise right and to keep track of time. You can’t spend more than about 5 minutes per step. You can in reality discuss this stuff for hours. If you are the designer for a real project, you won’t generally write on cards, but will just organize and moderate.
- One of the things I like about this exercise, or any exercise I use now, is that it isn’t a dead end. You don’t congratulate yourself on the team building exercise, but transition it directly into the next step, and eventually to actionable or testable items. Like this one.
- Objectives and key results. You need to be able to measure success, or quantify failure so you can fix it. If it helps, think of this as a product-level version of success criteria. You will evolve this to each feature, or define features to assure you are building the right thing, as you go along.
- But we’re not going to do that now. We don’t have time. Another thing we’re not going to do is talk about the audience. But I think it’s critical. Now, classic slow-as-molasses UCD types of teams can spend literally years and hundreds of thousands of dollars creating personas. Forget budgets, speed alone makes this impossible. By then, the world has changed. There are many ways to speed this up.
- This term I got from Kelly Goto, and I quite like it. You have in mind for your project — and I mean all your projects, and by “you” I mean everyone on the project — what type of users it will address. You do, but mostly you don’t actually say that out loud. Simply running an exercise like the KJ, with post-its and everyone in a room (or questionnaires, etc.) can gather all the information everyone presumes, and much that is actually known from previous projects and monitoring user behavior like sales. You can get an 80% persona with information on hand in a few hours.
- I don’t mean that Google has started offering a persona service. I mean using simple internet search to fill one out. I have done this, so successfully that others pointed it out in a meeting where one of these 18 month efforts was being presented: “but Steven made 4 pretty good personas in 3 days last week.” I did it by taking that presumptive persona information, then searching on terms that came up. This was a professional role, so I used LinkedIn groups, job postings and resumes. But you can do the same by stalking forums, blogs, and other internet properties where people of the role you expect hang out. A couple days can immerse you in the culture so much you can start to understand it quite well.
- There’s a lot to be said for taking even a little bit of time to do real research. Seeing how people really work in their natural environments is enlightening. This is a good example. As part of just testing a product related to this [MFV dongle] I was on site with these truck maintenance guys. Years into this project, I found this. They are, after many failed attempts like the thing he’s holding, disappointed with digital recordkeeping and data collection, so have a room of cubbyholes with paperwork. That had never come up. They didn’t think it was worth mentioning. I just stumbled across it. What are you missing by making assumptions about your users?
- The “one problem” exercise we did that’s all over these walls, you have noticed, is technology-agnostic. Even though I didn’t tell you to, it’s about users, and to some degree benefits your organization can gain. Even if you didn’t put down that you are going to gather their data to mine it for useful nuggets or sell it, the idea is at it’s heart marketable. Well the next step is to start modeling the process. But I want you to stay technology-agnostic, as much as possible. There are assumptions about the scope of the work that are based on technology, that you have a utility monitor or a wearable notifier. Ignore those. Don’t throw them away, but assume the previous exercise covered them,…
- And build a user task flow. This is about designing truly from the user’s point of view. Think about them, their motivations, their goals and the real, broader environment. About what they already do with their day. If it is raining, or they are driving vs. walking. NOT FROM SCRATCH. TAKE THE POST-ITS AND USE THEM AS KEY TOUCHPOINTS OR FEATURES. USE PAPER, OR EVEN JUST RE-ARRANGE THE POST-ITS AND DRAW LINES AND CIRCLES AND BOXES BETWEEN THEM.
- There are many ways to draw this. But most of all, make sure you talk about services, data, sensors, networks and users. Not screens, pages, buttons.
- It doesn’t have to be pretty. Just start with boxes, or even literally take post-its off the wall and start the diagram from the previous exercise work.
- If more comfortable with thinking about the user and their environment directly, this is a good place to use the storyboard. And, feel free to use several methods. Not just in your work, but now. Someone can draw the flow of all the data and all possible processes at the same time someone else is drawing a storyboard. But collaborate. Everyone talk, and grab the pen to take over if you must.30 MINUTES, BUT LIMITED!
- The next design artifact you will build is going to get much more specific. And if we have the time, we’ll even start making one. But before you can get there, you have to stop to understand again, and make sure you are designing the details the way the user will actually consume them.
- First, always work at device scale. Don’t do all the drawing on the computer. Don’t show off your designs on PPT to a conference room. For ONE]. A simple way is to draw on printouts the same size as your device. Any device. The Pebble guys had printouts the size of the expected watch screen.mobile interfaces, take your digital drawings as you progress through the design, and stick them on the handset. [SHOW EXAMPLE ON PH
- I assume you all know the story of Jeff Hawkins, even if you don’t recognize the name. One of the founders of Palm. He carried around a block of wood — supposedly this one, wrapped in tape and a paper printout — and pretended to take notes on it when he would want to use it. He got to try out the concept, in context, in much the way a real user would. He specifically focused on the form factor as a previous project had failed, he believed because it was too big to be pocketable.
- Me, I would have actually written on it or something. Which I did. This is me working on an eReader, before the iPad. Using my windows tablet wasn’t great because it was so big, and without a general-purpose computer to put screenshots on, I made a plywood tablet instead. We wrote on it, taped printed designs to it, and it was used when presenting early concepts to the clients even. Recently, working on a wearable I cannot otherwise discuss, we make sure there are mockups of the wearable around all the time. Mockups. They do NOTHING. Chunks of metal and plastic. But it provides not just an anchor for discussions, but you can really get into the mind of the user and think about how they will wear it, and how they will refer to it when it blinks and buzzes at them.
- Behind everything, there are wires, radio antennas, batteries, sensors, ICs, resistors, films, adhesives. If you are building for the real world, and don’t plan for when the world intrudes, you will fail. …Validate your technology… understand technology. ETC> BREAK UP INTO SEVERAL SLIDES.
- Understand your technology, and check yourself. There are many technologies you have to use. And all of them I see misunderstood very often. You will probably never use GPS for your app, but location, which is derived from many sources. Or displays. We like to pretend they are made of pixels, like when you zoom in to Photoshop, each one a square of a different color. But this is what a display looks like. And there are several variations. It can matter which one you are using, and even to the degree of managing power so battery life is all day, instead of an hour or two.
- Radios are a favorite of mine, I hear lots of talk about how mobile networks are slow, but that’s not /really/ true. They can be, but the best are broadly as fast as your typical home network. But they do have horrid latency. For various reasons, you can loose half a second per request. So, how’s that responsive site with a couple javascript files, every image loaded separately, some webfonts, etc? How long does your site take to load if you have 41 files at half a second each? Let’s do the math: Oh, too long. So, you don’t just cut down page weight, but you use single js files, or embed them. Single CSS files, or embed them. I have even made stuff with Base64 images, so the whole web page is one call. It works. It is worth the effort to optimize for your technology.
- So just as you get to understanding how mobile is different, we tell you that each radio is different. Who doesn’t know what BLE is? Bluetooth Low Energy. It’s not very much like Bluetooth, and is not at all like mobile networks or Ethernet. It is highly bursty and all about speed and low power consumption. And people screw this up. I am working on a project now I REALLY won’t name as I am going to badmouth them. They have a wearable that, among other things, blinks at users. It does this by the mobile sending the signal “you, turn the light on,” then after a bit “you, turn the light off.” That’s insane. The kind if way to use it instead would be to load the configuration data to the wearable when the use saves it, then send tiny, one-character messages to say which one to fire. Or, how often should you poll for battery life? HANDS Never. Have the device itself send a signal, which can be part of the “advertising” message, which is broadcast to anyone. BLE lets you put data out there without pairing, which cuts down on time and power for public knowledge like this. This is all just an example. You should know how location really works, how screens work, about accelerometers, cameras, magnetometers, batteries, power management, … everything works, at least a little.
- In case you think this is all on the implementation side, so you’ll worry later, wrong. The software design, the interaction design, and even the information architecture and data concepts can induce failure if you are not careful. Right now I am working on a revision of the system that uses this [MFV dongle]. This is a prototype, and the real one will be much, much smaller. Anyway, we built the product to live read a remote system. Much, much, much later we found out it cannot be live, but gets snapshots of the remote system. Like, after it was built.
- We tested it, and even with a few tweaks, it didn’t work. The concept of the app design didn’t make a bit of sense in fairly fundamental ways. We have video, which I cannot show you as the app is secret, of people failing to do what we expect. I am just finishing a moderate redesign of the interface to reflect the way the system works. These are non-trivial differences, as it turns out. You can’t add a button or explain it, but have to build the interaction around the way the system works. Tab bars went away entirely, the menu items all changed. The first several pages we show people every time they enter the app… gone. Serious changes.
- So with those fears in mind, let’s design a system. Not an ecosystem, but a single system. You are going to take the task flow, and now we’ll make it platform specific. In reality, we’d branch it to the many platforms needed, and should even make as part of this exercise identifying the various platforms. Here, go ahead and assume one exists. Whichever was posited during the elevator talk at the beginning, whether smart shoes, or a thermostat better than Nest, that’s the platform we are using, not the desktop website or the mobile app. Go through the task flow, and mark all the points where you are sure the connected device will have some input or output. Then, pick two or three of these vertices, as again we only have a little bit of time, sit down, and design the interface and interaction that goes with these.
- Then, and mostly, I want you to describe what is happening. You may also draw. Not just flows, but interfaces and interactions. But then describe the interactions. This is where I get ranty about not prototyping, but drawing and describing. As we move to these all-new and arbitrary devices, you can’t code them up. They might not exist as you create the hardware. You have to be able to draw and specify things like the lights, the blink rate, the way the user shakes or waves at it.
- And don’t get hung up thinking there’s no UI. The NoUIthouhts are rather clever. I argued with Don Norman about it a bit when Cooper had a little workshop on it after that article by Krishna Golden, if I remember his name right. But he really meant “UI that is different from a screen you touch or a keyboard.” Blinking and buzzing is output. Sending user movement is input. Wiring your thermostat, or plugging in your wearable to charge every night is absolutely an interaction. Think of all those, and design away. Now.20 MINUTES.
- While you do that, I’ll remind you think is an extension of the previous drawings you did. This is a mobile phone app, but that’s the only one I can show you now. You don’t have to, ever, jump to “now we’re doing wireframes” or worse “comps.” Keep with the user-centric methods. Here, it’s screens, but the user is shown walking down the streets of Nairoi. And it’s not all the app. The first screen is SMS, then he goes to the Website, where he’s enticed to download the app. You can show flows and interactions and user context. You probably should.
- The developers here especially may be familiar with something called SIT, or some variation of System Integration Testing. It’s an end to end technical test of the system. First, it’s increasingly a lie. Are you testing on the real hardware, on mobile networks other than in your corporate office? Outside? With noise and glare and distractions? Because those all matter. The system includes people, so we break that up into usability tests as well. MOVE ALL NOTES ABOUT VALIDATING TO HERE. You SHOW OFF GLASSES AND DISCUSS HOW YOU HAVE TO CHANGE TESTING TO THIS WORLD. ETHNOGRAPHY, ETC.
- First, yes, you should understand. Make sure the system basically works. Check the hardware and make sure your fundamental assumptions are correct. Here, we’re trying out the UI on an ePaper device. There’s very little info out there on design for ePaper, so we had to do it all experimentally. Using this view camera and trial and error to make just the colors readable. There were many other parts to test of this.
- Test, test, test. Test on real devices, not just emulators. First, in your office, like this maybe. This is me trying out a responsive app, to make sure it works right on as many devices as I can. If you have a multi-screen experience, get the phone, desktop and smart watch out at the same time, and do end to end testing to make sure it doesn’t just work, but makes sense. Wear it around, try it. Does it work in reality?
- Test in the field. With real hardware, in real circumstances. With real users if you can. And, you can. User testing is not that hard. In fact, I find that not having a lab makes it easier and cheaper. You have to know how to test — how not to mess up the results with your opinions — but you go to the users, so they are easier to get ahold of. Here, were testing this dongle on trucks. The photo is from the user’s point of view. He wore these video glasses so we can review the work later. Even the data gathering is literally from the users POV. That helps, and you see stuff you couldn’t get later. As you see here, we also are getting off the screen. We capture everything the user sees, not just the handset. This is GREAT>>>> IOT DEVICES>>>
- If you miss these addresses, just Google my name and you’ll find me.
- Just trust me on this one: Everything you do 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 learning information. You could just remember instead…
- I say there’s something called Resilience Design. Or there should be. Here’s a simple example… 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. But on mine, and on all dive watches (vs. Aviators 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, 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.
- You need to make your designs resilient because users will never, ever do what you expect. You, or others in your organization, probably draw diagrams that assume everyone starts at the home page, drills down through a preferred path and gets their information. It’s not true. People bookmark, share, and search. They use your process in unexpected ways, and your system returns errors or data you didn’t expect. If you try to design to accommodate these, or to test for them in the traditional use case model, you CAN’T. For one project I worked on, I did some quick math and to create the use cases for all variations would take approximately the remaining life of the universe. Really. These are arbitrarily complex products, so don’t lament, embrace the complexity.
- On a typical website, I find that home page as the entry point is rarely over 10%, and is often so low as to be ignored; hundreds of visits a month when hundreds of thousands visit the site. This is real data.
- This is even more important with the way people engage on mobile devices. People seek out and consume content sometimes a few seconds at a time. They get interrupted, and come back to read a bit again so it has to be ready for them. Does your information work well and make sense if set aside for a few minutes? A few hours? Make sure session expiry and other technical things don’t get in the way of users coming back. And, remind them to come back. Use SMS, and app notifications or reminders within the site or app of items that may be interesting or that they didn’t complete. Or emails. Or postcards. Or whatever fits the way you have a conversation with your customers or users.