Downloaded 106 times
Uploaded bySteven Hoober
Design for Every Screen
The document discusses designing interfaces for mobile experiences across different screens and platforms. It recommends taking a user-centered and service design approach to create a blueprint of the whole experience before designing interfaces for specific channels. The blueprint involves gathering information, defining personas and goals, listing all possible features, filtering to only necessary features, grouping by dependencies and priorities, and arranging notional interfaces. Interaction designs and interfaces can then be created for each channel by further filtering the blueprint and optimizing for interactions and interfaces on that platform. Communication and buy-in are also discussed as important to the design process.
More Related Content
Similar to Design for Every Screen
More from Steven Hoober
Design for Every Screen
- 1. Design for Every Screen DesigningMobile Interfaces: Patterns for Interaction Design 1
- 2.
- 3. Design for Clients “Whatwe need is… “ • Trends • Fashion • Competition • Please the boss 3
- 4. Design for WhatYou Know 4
- 5. You Are theMobile Team 5
- 6. Design for EveryScreen 6
- 7. Design for Everything • Desktop consumer web • SMS • Mobile web • MMS • Mobile app • IVR • Store terminals • TV • Call center terminals • Projection • Call center logging • Touch • Call center scripts • Gesture • Kiosks • Shared interfaces • Printed bills • Pen input • Bill inserts • Biometrics • Envelope printing • Location • Emails • Environments 7
- 8.
- 9.
- 10.
- 11. Design Principles • Gather information • Design for users, tasks, and goals • Do not design for technology, interfaces or platforms • Create a blueprint of the whole service • Design to target experiences Use that to create IAs (and then interaction flows, wires, etc.) for each channel. 11
- 12. Design for Users User-CenteredDesign informs your decisions. Before you can design, you have to define: • Audience • Purpose • Context 12
- 13. Design for Services ServiceDesign principles may inform the process even more. Key elements that have to be defined, using formal processes, are: • Actors • Scenarios • Components 13
- 14. How About anExample? 14
- 15. Every Platform WeCan Think Of 15
- 16. One IA forAll 16
- 17.
- 18. One IA foreReaders 18
- 19. Another IA forWeb 19
- 20. Blueprint the IxD& Interface 20
- 21.
- 22. A Checklist forDesign • Blueprint: • Gather – Collect info • Define – Personas, objectives • List – All possible features • Filter – Keep only what you need • Group – Cluster and establish dependencies • Prioritize – Earlier and higher, in system or backlog • Arrange – Notional interfaces • IA, IxD (per channel) • Re-Filter – What cannot, should not be here • Branch – Executable IA • Optimize – Interaction, and interfaces 22
- 23. Implement for EveryScreen 23
- 24.
- 25.
- 26. Gain Buy-In 26
- 27. Steven Hoober steven@4ourth.com +1 816210 0455 @shoobe01 shoobe01 on: www.4ourth.com 27
Editor's Notes
- #2 I tend to be among those who are regularly bucking trends and asking difficult questions. But I am not just a naysayer for the sake of being one. When I find that something I am doing is wrong, or misguided, I try to fix it. Ideally, I work with various types of success metrics, and when things go poorly, I know it, and I can work to improve them. Much of my process is, therefore, proven to be good. But it also means that every once in a while I discover a gap, a failure or a new idea that something sets me off, and proves that what I thought was the right process -- or even my existing understand of what I already do – is missing something.
- #3 During some of my latest projects, and while developing the just-released book, I’ve been thinking a lot about what “Mobile” means, and what that answer means to the other channels you also have to work with. Let me quicklyrun down what I see as the problem with a lot of projects, or in a lot of organizations.
- #4 A typical project starts with a client requesting something. Here “client” can mean a real third-party client paying actual money, or themarketing or product development guys at your enterprise. Often, they arereacting tosome VP who asks for something specific, or the competition who just came up with something that could be perceived as an advantage.So, who wants to annoy the client? Of course you do what they want. Even if it’s a local tow company app. This is real. I did not work on it. And I cannot tell why it exists, EXCEPT because a client thought it was a good idea, and no one stopped them.
- #5 Or, left on your own with vague direction, you design for what you carry around every day, or what are comfortable developing for. And no one challenges you. I mean, how many of your co-workers carry something other than an iPhone? But does everyone in the target audience carry the same device as you, in this configuration? Look here,… I’ve tested on iPhone AND iPad. It must work fine. All too often I’ve seen almost zero use of a new, expensive-to-make app because the audience doesn’t use the platform. I mean, literally dozens of downloads for Fortune 100 brands.
- #6 No matter how much people say “mobile first” when concepting, when strategies are made and budgets signed off, mobile is still considered “something else.” Even if it’s not “oh, by the way, mobile stuff (as in this picture),” it’s still considered an offshoot or special case. So it’s not considered as part of the whole strategy all at once.As a member of the mobile team, or worse, some silo like “the iPad team,” you are simply given assignments to design and build for your platform. Probably even on a timeline that has nothing to do with anyone else, or with third party developers, so you can’t even share webservices.
- #7 Instead, I say you need to push to Design for Every Screen, right from the start. Please be aware, I am not advocating any particular position on which gets development priority, and am about to say “design for Android, as it’s got more marketshare.” It is not even just about there being many, many devices, and class based design, and strategies to avoid fragmentation. I don't want to get caught up in that particular argument. It's a convenient side effect, but not what this is about.(Before you ask, I own all these devices, and actually quite a few more.)
- #8 What it is about is this.I mean you need to design for every context, every input, every output, andevery channel,regardless of devices. (This is just some of them that I have actually worked with).I find that when you explore the boundaries of a project, even a pretty narrowly-defined one, it ends up working in more channels than the topline definition, and ends up having a lot more inputs and outputs than you would have guessed at first.
- #9 What we’re really talking about is Designing for the Experience you want the customer to have.Think back to thrilling technical experiences of the pre-connected days, if you are old enough: you popped open the box for your new Mac, and the whole experience was beautiful. Not just the device and software, but the box, the way it opened, the manuals, the labels on the CDs and… everything. Even then, it was a designed experience that all went together.
- #10 But now, EVERYTHING we design is connected, networked, cloud-stored. EVERYTHING is an inherently multi-channel experience. Instagram (which I did not work on), for example, is regularly talked about as an “iPhone Only” application. But is that really true?
- #11 Of course not. Every app has to be sold and downloaded. So it has a desktop (and mobile) website, and an Appstore presence. And their website is rather nice, so has other information like help documentation. It’s not just a gateway to the app or store.This is a sharing service, and a good one that doesn’t only work with your friends who have downloaded the same app. There is a way to view the images on the web as well, for anyone. And they implemented a URL shortening service to make this easier to do, of course. Many of your “only on this platform” apps will require emails, SMSs, MMSs, links to Facebook, maybe even printed things. There are lots of customer touchpoints, and building just one won’t work well.
- #12 So, what we need to do is design not just for the primary channel, or muddle through and catch up later when we realize what else is needed. Instead, we need to proactively design for the for the entire product experience, before you design for any one experience. Learnall you can about the enterprise and the user, so you can design for the user’s tasks and goals.Start by – as much as possible – ignoring technology, interfaces or platforms of any sort. Create anIA for the entire system (which I call a Blueprint), with no (or every) interface in mind – and the end goal or Target experience in mind, not just what is in this release.Then, when that is sensible and approved, you build each of the individual channels out. If this seems like a lot of extra work, it’s not as it makes later work more efficient. It’s not just a way to improve the overall experience, but a better way to work.
- #13 And, it’s not learning a new process. It’s stuff you already do. You just need to make sure you are applying the right approach to those existing processes. Going back to something as well-defined and foundational as UCD, you just need to back up a half step until you no longer make assumptions about technologies. Usability-DOT-GOV, with an otherwise rather good summary of UCD, has as a tagline “Your guide for developing usable and useful WEB SITES.” Many others assume the same. In fact, if you go back to principles, you will see that your existing processes work just fine to define experiences regardless of channel:Use personas, and anything else you can use to gain an understanding of who will use the product. Build scenarios and use cases to understand how the product will be used, what tasks and goals exist, and what features will be helpful to get there.Yup, we're back to contexts of use again. And, you'll see again that context is a fundamental to understanding the use of using any system, not just mobile.
- #14 Service Design is also an interesting approach to take. I’d always been aware it was a design field, but “something else” that I do not do. But its interesting, how it is multi-channel, and systematically-focused.There are, with that, incredible parallels to UCD principles. Identify all of the actors involved in the definition of the service. All the end users, as well as all of the employees who have interactions with your customers, or who manage content or systems.Defineall possible service scenarios, verifying use cases, sequences of actions and actors’ role, in order to define the requirements for the service and its logical and organizational structureRepresent all the components of the service, including physical elements, spatial and digital interactions, logical links between components, and timings or delays. Which sounds to me a lot like understanding how context of use influences interfaces.
- #15 Instead of more philosophy and theory, how about an example. And this time, one I have worked on. It was hard to come up with examples to share. I fell into a lot of these traps previously, so am not always the brilliant designer. Or projectsare still secret, so hard to share without being yelled at. But this is out there in production, was a couple years ago, and others I worked with have it on their portfolio pages, so I think it’s a good one.
- #16 It was an eReader, to have dedicated e-Paper hardware, but also was to be a platform and service that worked on the desktop/laptop.And mobile phones. Full-reader on smartphones as well as some mobile web use for every handset.And… once the iPadcame out, tablets. And… there was a deal with a top PC maker to pre-load it onto their family-oriented touch-screen devices, so it had to work at kiosk scale, as well as for 10-foot UI, when plugged into TVs.And… probably more than this but I cannot remember them. So, what platform did I design for first?
- #17 Well of course, none of them.At least that’s what a lot of the dev managers and acct manager said. But I turned them around (I think) to an understanding that I actually designed for ALL of them. This diagram was called an Information Model, a Content Model and finally a Sitemap, as it’s a word that everyone could understand. But now I like to call it a Blueprint.
- #18 A Blueprint, in the architectural and engineering sense that there is a single stack of drawings, bound up (even in this digital age) which can be glanced at to get an impression of the whole project, or the whole system. Which is then broken up to get to specific sections or tasks. The electricians, for example, only care about the wiring diagrams. To the point where many of them are only given those few pages for their work. But it would be insane to have a dedicated draftsman and designer actually make separate drawings for them, with little or no relationship to the architect, structural and mechanical engineers. It is all conceived as one, and then broken out to add details and communicate as needed.
- #19 Which is the same way I did this product.The blueprint is branched to IA diagrams for the specific interfaces or platforms, like this one. Certain functions disappear, and entry points change to emphasize the value and key function of that particular interface or platform.
- #20 And here, another IA for the desktop Web. For legal/licensingreasons, reading is not allowed, so those sections disappear, and we send the customer to the portal landing page, and encourage them to purchase and manage instead.But again, it’s from the same Blueprint. Even when the individual interaction changes, the language of design used is the same so the experience of the product as a whole is the same.
- #21 The same method works for individual interfaces and interactions. The entire project was built in modules, with a single common (blueprint-level) wireframe and specification developed for each of those modules. They were then re-used across each of the platforms wherever needed. Here, a universal notifications bar is shown in general wireframe mode, and as it finally appeared on the iPad. A similar implementation was on the eReader.
- #22 But on the desktop, docking to the bottom of the viewport was not entirely feasible, and bottom-of-window wasn’t wholly sensible. Instead of just forcing this sort of consistency, the same basic architectural solution – even with similar visual look – was used at the top of the window instead, where users expect it on that platform. This is the sort of branching to interface specificity that you can and should do. I’ve done this a lot in smaller scales with making sure – for example – that the menus for iOS, Android and Blackberry are not identical for the sake of single-design or consistency, but keep a thematic and architectural appeal while reflecting the interaction that users of these devices are used to.And, the same happens for less interface-oriented inputs and outputs. Emails (or SMS) should not just be hacked out at the last minute to meet functional requirements, but need to be designed in the context of the entire system, to feel that they are integrated components of the experience.
- #23 --- To make sure I design correctly and don’t get ahead of myself, I have to make processes, or checklists, to follow. I am not going to read you each of these – If really interested, check out my older book on design process or download this presentation. Fundamentally, it’s a really simple process I have been following for years, which I more recently realized needs a split. The earlier phases are for the entire experience, the Blueprint of the whole system. The later phases are when you branch to specific channels or interfaces.Two things I do want to point out are:Filtering out features, to make the most simple experience possible at the Blueprint level should help prevent what you might call “mobile simplification syndrome.” Every channel gets all the features that can technically be made to work and you can reduce the inclination to add features to the desktop web, remove them from the mobile web, for example.When you filter for each channel, that should be more about what cannotbe there. Device settings like brightness and volume are only on the device, and not in the settings panel for the website, for example.All these diagrams, even the channelized IA diagrams, should still be for the target experience. You design not just for every channel, but for every possible channel, and each of those to what you can envision today is the ideal state, if you had unlimited resources. Practically, this will be about 2-3 years out. Some constraints are fine.So, when you deliver to an implementation team, you’ll have to cut out features for release 1. In some processes (Agile) this works great, and you can deliver the target experience along with a prioritized backlog (and some dependencies). They get as far as they get, but everyone knows the target.
- #24 Speaking of implementation, akey gap to getting a good, holistic experience still exists: the Gulf of Execution. No, not Don Norman’s gap between stimulus and understanding, but the difference between what you give as a design,and what comes out of the development team. I'll come up with a good phrase to replace that, someday.I know some of you develop your own code, already has a terrific relationship with their developers, or believe your process solves all. I’ve been there and say: Some day it won’t. Even if everything is wonderful, can it be better? Usually. At least, find out why it works so you can fix your next company.For everyone else, if you design holistically – Systems; not pages, not widgets, not buttons – but if you design as I've been saying with extensible, system-agnostic architectures, and end-to-end experiences, your developers can work the exact same way. Forget similar outcomes, and tweaking code to look like your Photoshop (or Fireworks) comps; there is no better way to assure implementation as planned better than to design the way it’s all built.The image here is the legend of modules from the corner of the blueprint I showed earlier. To the right, a couple of the modules are explained in more detail. I rarely build wireframes that are each screen in a system, as that’s impossible. There are too many states, and they become hard to understand. So, I build architectures, grids, wrappers, templates and modules. Individual modules get wireframed and comped up as needed.
- #25 There are a couple more principles you should keep in mind to assure good outcomes for your design.Develop objectives the team canunderstand, and embrace, which can be achieved by them, and can be reflected in the product you are building today, and tomorrow. I like to post objectives on the wall, and sometimes as shown here, the architecture or information design if it communicates the objectives well. I made about a dozen of these diagrams, then posted them in each design or development work area. And, since there were minor revisions, I re-posted them periodically. Which was a great way to be visible to the teams as well. And I know this is valuable, as I learned I could not take them all down, then put up all new ones. Before I got finished, one or two people would come to me and demand to know where the poster went, and how to get a replacement. Once, I didn’t get a chance to put it up, and the developer grabbed one from the stack in my hand.
- #26 You are the designer, so you must take ownership of your design – You can't just put a target design on the wall and assume it will be built, or periodically ask how things are going. You have to believe in what you give to the, stick to that belief, and keep helping everyone to implement the existing plan with each future release.Here’s a good example of how I had to work hand in hand with implementation. A key challenge of the reader was making sure the books (the whole design, but especially the reading experience itself) worked on all the hardware. I did a lot of typical tests and used existing heuristics on handsets and desktop. But lacking published heuristics -- or even accurate tech specs -- for the ePaper displays and drivers, I had to make up my own design standards, based on psychology and physiology fundamentals, and experimentation.I had to work very closely with the implementation teams to do this research, and get my changed designs in place, since we had to do it very late in the process. On the screen here is very early hardware, and the head of reader software development using an Elmo I had set up to capture and measure output through the screen.
- #27 You may have to go quite out of your way to get buy-in for your designs. It’s best to get this from the first concepts you develop, but you have to maintain that dialogue throughout the process. A key part of this is to make sure everyone understands what you have designed. For this project, it turns out no one had experience with eReaders, so one thing I did was made a plywood one in my shop (screen is whiteboard, and sized to fit half-sheets of paper) and we could use it for quick paper-prototype sorts of things. An owner says “9 pt? That seems small” and you print it and show him. This is not typical, but it’s what this project called for. Whatever you have to do, make sure the whole team believes inyour concepts, objectives and design details. Remember, you can't do it all alone. Even if it means adjusting to get a plan and design thateveryone can get behind. Not just live with, but actually believe in it.
- #28 Anyone who wants a (printed) copy of the book can get one from me here, today, or they are for sale on Amazon and O’Reilly, in paper or every conceivable eBook format. Be sure to visit 4ourth.com to read it online, and get updates, especially to the design and test resource lists. And, please add to the discussion if you have other information. This presentation is already up on Slideshare, so you can download it whenever you want. But now, what questions do you have today?