Design for Every Screen

Ever since mobile became really, really cool when the iPhone came out and every designer could happily show off their mobile credentials by having the latest one, there has been an influx of great new ideas accompanied by pithy little catchphrases. I've been somewhere between suspicious and dismissive of many of them, sometimes fairly publicly.

For all the good it does. Here I am mentioned being perceived as agreeing with Mobile First alongside Luke Wroblewski and Scott Jenson, up on stage no less. I never really did.

But lately I've been presenting a bit, and otherwise talking to folks all over the place, and therefore thinking more about many of these topics. First is that I promise I've never just been deliberately contrary, but none of my specific arguments ever stuck that well. And second you should know that I do not just make assumptions, but try to get to root meanings in order to act on information and do my job better. Just check out my work or how long the book is for proof. You can't shut me up when I get on a topic.

I also get tangential. Back on topic, I think that I'm suspicious and not embracing of a lot of these catchprases largely because I have gotten into this field differently than some others. I did art and graphic design from the time I could pick up a pencil, but was engineering-focused from Jr. High onward. I did grant-funded aerospace research in High School. I was the first researcher in the water tunnel at Wichita State University. But when I got to college I sucked at statics & dynamics, and some of the math, so eventually had to leave the program and fell back to art. Learned a lot of good stuff about competitiveness, criticism and understanding design reasoning there, so it was good in the end. I did graphic design work before I even graduated, which immediately (1995) was followed by "can we make a website also" requests from clients. Over a couple jobs I moved from my previous understanding of holistic design to true interaction, human factors, HCI and the emerging fields of UX. I formed teams and we taught ourselves how to be good designers of interactive systems.

So, despite pretty much getting into mobile from the web design side, it always involved data being fed from old systems, terminals for customer care reps, or email, or mailers or magazines. Or often, several of these.

I've been designing for multiple devices forever, since at least the late 1990s. The same stuff in print, CD, TV, web. Envelopes to put the brochure into. Etc. For another currently-cool example, I've been doing little hacks to dynamically resize and reflow content to different browser windows for years – so much so I keep forgetting that it's now called "responsive design."

If you think any one screen, size or channel solves your problems, think again. Netflix has to have a TV UI, sure. But have you noticed the Wii has a browser? Or what if Google TV stops being terrible, or Apple does break into TV in a big way after all? You'll need a 10-foot UI version of your website, and it's no longer just a real big PC monitor; just Monday, a report that console games are the #1 way to get online content to the TV. You might need a TV UI version today. Or yet another app for yet another audience. Technology isn't done growing, and sticking to any one technology is as bad as any other.

I've started calling this – at first somewhat by accident – "design for every screen." As you read on you'll notice it's not quite true, so I admit it's my own clever phrase. But it's closer than a lot of others, so I'll stick with it.

Devices and Channels

Another one of those marketable bits of phrasing from the past year or so was deciding that mobile context is no longer interesting. So I'll admit right off we're closing in on what I always called context. But "mobile context" has itself become saddled with improper assumptions of its meaning. Instead of throwing it away, I think we need to resurrect it.

Partly, because I cannot think of a better word. But also because I've been using the phrase for at least a decade. I went and looked a few weeks ago, and indeed have design documents from 2001 talking about the context of use. These were about the difference between consumers, several types of account managers, and call center employees, each of which had different levels of knowledge, training, etc. For a desktop web interfaces. And some had different use contexts, on the road, in an office, on specific hardware we knew about.

Mobile just added one more context when (around this same timeframe) I started tacking on mobile interfaces to the account management portals. But the then it added dozens. Doctors are not financial analysts, even if they both live by SMS and BBM. The growing variability in use of mobiles made them just like the desktop web. Meaning, lots of them.

Sure, there are some special contexts, because you use them wherever you are, instead of at a workstation of any sort.

And, the variability is bigger than you think. How many touchpoints do you have with a typical service, or company? Paper and ebills, other mailers, websites, and that's all supporting, before I get to the actual service which might be on the web or an app or a set top box. And more all the time: I watch TV on the website for my satellite provider more (when traveling at least) than through the set-top DVR.

Let me get back to some specifics, so we can talk about real products instead pure philosophical arguments. In the mid-2000s, I spent a long time doing a series of billing and account management projects, basically centered around some web portals. But only centered there; lots of other access points existed:

• Desktop consumer web
• Mobile web
• Mobile app
• Store terminals
• Call center terminals
• Call center logging
• Call center voice communication to the customer (scripts, etc.)
• Kiosks
• Printed bills
• Bill inserts
• Envelope printing
• Emails
• SMS
• IVR
• And probably a couple more I forgot.

When I look back at my project files, it turns out most projects I work on are multi-channel, even if not multi-device. If you are just making an app, it's hard to not have a website, optimized for both desktop and mobile. And you better think of how it will look in app store, and how it installs. And... so on.

Design for Every Input

How about design for every input? I spend a lot of time reminding everyone that it's not just touchscreen, but also scroll & select; even lots of touch devices have keyboards and the very large category of messagephones are just 10-key scroll-and-select devices when folded. If you pretend everything is touch only, then your app looks stupid when it won't work right with the keyboard out.

But did you remember other inputs? Take a video sharing service (like some I have worked on). Why make users go to the desktop web or download an app, just to upload? We added MMS and Email services. Send to a specific address, and it goes into your account. And, this worked great. These are popular services. Do I need to remind everyone that Twitter is an SMS-based service? How can you leverage other channels to allow user input?

If you are not following my logic here, it's just an extension of the previous thoughts that everything is slightly more complex than it appears at first. Even if you stick to the desktop, web is just one input/output channel. You send customers emails, and then they can respond. They can call you. They send back bills in paper, no matter how much you wish they wouldn't. This is all part of the experience and you better address it all at the same time.

Design for Every Screen

Generally, when I talk about these principles, everyone agrees. I come away from client meetings with a task to show some multi-channel scenarios, or permission to architect the system with device agnosticism, so we can discover the right channels organically. And that works fine.

But like a lot of my processes, it doesn't work so well when I task others to do the same thing in my stead. I'll even make those basic deliverables, and then move on to another project while just supervising further design development. And it still falls down. So, we need to come up with some methods by which design for every screen can be carried out.

Well, not really. Because they already exist. Pretty much every design methodology will work just fine. Process I have published work fine, but let's go more generic. How about some basic tenents of UCD. If you can find a definition that doesn't get all hung up on a channel (really, Usability.gov only websites need to be designed?) you will find some of the same principles I've been talking about:

• Audience – Personas, and anything else you can use to determine
• Purpose – Use 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.
• Context – 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.

The difference between a lot of practice with these processes, and what I want you to do is two-fold:

1. All answers are valid – Do not set constraints, or make false assumptions. Let the process lead you to audiences, purposes and contexts you might not have thought of.
2. Actually follow a design process – This is key. No one does a design process anymore. Even people who gather at monthly meetings to talk about how great process is, read books and chat about it, end up just sketching ideas immediately. And the sketches are in their domain; if you are a web designer you make a desktop website, if you are a mobile designer, you make an iPhone app. Always.

To reiterate: cut it out. Pop open books if you need to, but gather information, answer your basic questions and develop whatever else will help you. Even if quick and dirty I say you should always be putting problem statements, principles of design and personas up on the wall. At the least. And you can do this in about two hours if you need to. It's not something that has to take six weeks, or six months.

Design for Target Experiences:

There's a third facet you'll need to stick to also, but it's less about principles than communicating to clients, so I didn't include it in the list. You may have already figured it out, and are sneering at my rainbows-and-unicorns world where everything we want gets built. In reality, of course, there are time/people/money budgets, and only a few things get built. So, you are still only getting a website

At first. You, as the designer, need to keep saying "the first release will..." and then keep putting up IA diagrams of the target experience. This is a great phrase. Unlike "problem statement" or some other things that cause grief and need euphemisms, "target experience" goes over great for all levels of IT and business folks. We want to be here, but we also know that pragmatically, we can only go this far... today. Keep saying it like that. Be and act realistic about the whole thing and you'll be surprised how much you get snuck in.

And not in an evil sneaky way. "Sneak in" would be one of those phrases you do not use in front of the clients. What I mean is, go back and look at some of those inputs and channels above. Your product will have email, SMS, printed bills, customer care. Or at least a few of these. Nothing is a pure website. So when you design for every screen, you are not surprised by a sudden request to make the email messages not terrible, 3 months after launch. You designed that, along with all the right error messages, and an easy upload scheme, right from the start. If it's getting built anyway (like outbound email), then your design goes in on the first phase.

That is because this also works very well with a lot of product development and software development processes. They like plans. Agile, for example, actually has a backlog of features. You can simply fill up the next 18 months with features, immediately. You are not perceived as annoying and overbearing, but as a go-getter, trying to make the product as good as it can be. The first person to show up with a list of functional requirements (or Stories, or Features, or whatever) has more influence over the final output than is immediately obvious.

Design for Change

Of course, you will learn as you go along. And you will learn you were wrong. User tests, analytics, customer-satisfaction scores, close rates, will all tell the real picture. Your second phase will become less important, and something else pops up, for example. But you will look okay, as you've got a target experience. Which is just a target, you must be willing to shift to the data, and say that out loud.

And, you will not be surprised by this – at least not entirely. Because your multi-channel, IA-based target experience looked at everything. You've at least got a sketch and a set of bullet points. When research comes back with a recommendation that you are years behind the times, and you better do something better than Usable.net for your mobile site, you can pull that out and be helpful and speedy.

As long as you are not "told you" and all arrogant about that. There's a limit to how much you can trust my client-relationship advice.

Implement for Every Screen:

A key 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 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 their own code, already has a terrific relationship with their developers, or believes 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. Even if not enough to mess with, find out why it works so you can fix your next company.

For everyone else, there's hope. And not the passive hope that this next development process or corporate reorg fixes everything. They will embrace your principles, which for this stage we can define as:

• Design holistically – Systems, not pages, not widgets, not buttons. Just like I've been saying, design extensible, system-agnostic architectures, and end-to-end experiences.
• Develop good objectives – Tie to the enterprise, and the product owner, but develop objectives for the team to embrace, and which can be achieved by them, and by the product you are building today, and tomorrow.
• Own your design – You can't just put a target design on the wall. You have to believe in what you give to them (without changing your mind halfway through the release), and you have to keep reminding everyone to implement the existing plan with each future release.
• Get everyone to buy into it – You can't do it alone. Even if it means adjusting or even collaborating get a plan and design everyone can get behind. Not just live with, but actually believe in.

I've developed a few tactics over the years to help with this. Actually, a lot more than this, but these are the key ones. And they aren't a trick or a stretch. The design process I've been talking about, the process you have worked through to get the the implementation stage is very much in line with good software development. All this makes sense to implementation teams.

• Don’t walk away – Always stick with the project through development, at least making yourself available for questions, rework, changes and testing. Ideally, become integrated into the team, and attend daily meetings, test planning, and so on. Plan on this from the start so your schedule and budget accounts for it.
• Set goals for everyone – Those business and user goals you should have developed at the beginning of the project must be translated into actual, measurable metrics. Then, try to make sure they get measured. Push for these to be the project level measure of success for the whole organization, instead of cost savings, efficiency of developers, or other internal measures.
• Make object-oriented designs – Sometimes this is just called “modular re-use,” or other things, as “object oriented” is a larger set of principles (it all originated in development) and might confuse development. But I like the sound of it. The core concept is the same: Instead of designing every detail for every state, and building by state or building hundreds of items to bolt together, a few dozen modules are built and re-used over and over in common templates. Easier on you, and easier on development if they work that way.
• Practice polymorphism – Sorry, it's another of my troublesome words; this time, not bad, just meaningless to many people. But developers tend to love it. Essentially, variations of objects are still the same object. If there are several variations of an on-screen module you design, make sure you express them as variations of each other so these are clear. This is a polymorphic item. Of course, if there is only one variant (omnimorphism) then that should be explicitly stated as well. Always keep in mind efficiency and re-use.
• One IA for all – As discussed at great length above, a single IA diagram will give everyone a single, simple concept to hang onto. Enough, that developers will stick it on the wall of their cube. This is the best you can hope for; most developers won't put design objectives or personas on the wall, but this isn't bad.

As I said, there are other tactics and facets to remember, but they start getting pretty detailed again, so are almost a side conversation. Don't forget branding, and to communicate in a single voice. Good design will automatically be accessible, multi-platform and easier to manage and implement. And so on. I suspect if you have a design/implementation tactic, I believe in it also, and just say: don't forget to add it to your checklist, and start thinking about it as early as possible.

I have used a lot of my own experiences above. But those, and the long time I have been in mobile (or doing these other things) is not even important. I have worked with others who had their first mobile experience while I watched, well into the everything-is-a-smartphone era. And if they have a similarly technical background, or a systems-thinking approach, they do just fine approaching the design not as mobile first, but appropriately, bottom-up, and with every interface and interaction the end user needs.

Anyone can, and should be designing for every screen, every input, every device, and every context.

Insulting your customers with poor process

Most process and customer service is bad, so it's more often exceptionally good things that are worth noting anymore. It takes something really bad to make me annoyed enough to tell everyone. But today I am with my Dad getting an MRI for his ongoing cancer thing and we had to go to Shawnee Mission Medical Center. Most hospitals seem to have gone to this system, which I guess they think is providing extra customer service, where you have to check in at the front desk. Then they have you fill out some paperwork in a cubicle and someone – usually the person who has been with you the whole time – walks you to the department you are visiting. SMMC tried this, and failed. It's particularly galling as they are just finishing a huge expansion, and the hospital is now topped with a large, green glass polygon. The reception desk is immediately inside the front door, so you have to wait in the drafty lobby. Did I mention the waiting? Two stations only, and you apparently (we pre-registered) cannot get out of there in under three minutes. Some people take over 10 minutes. We were in this line for a long time, and there's no need for it. We didn't fill out paper at the cubicles, but I was there long enough that it was clear what was happening. The reception desk people, who take too long anyway, then make you wait in a waiting room. Eventually (based on the number of people there and how deeply they were into their magazines) they call you. Privacy of course means they cannot, so they say "Sheila, last name starts with D." Escorts are the worst part though. As in some places, they are senile volunteers. But these guys sit there behind the main reception desk, drinking coffee and joking. So you come up and see a long line, two people working (and sometimes they walk away so its only one) and a bunch of folks not apparently helping. This is expressly annoying, and was overtly so not just to me. But the poor escort system doesn't stop! The old men are not paying attention, and are hard of hearing. So, the reception person gives them a folder of critical info you need to get your procedure done (they give you nothing) then he wanders off and comes out several yards away and starts yelling your name. Even after I said it, and raised my hand he was confused and stopped everyone to ask "are you Scott?!" Then he helps you by walking slower than even old, sick people, and points out the way to the MRI department, which otherwise you'd never find, I guess. Poor process can prevent people from concluding tasks, or it can be part of something they are already dedicated to or are required to do, and it just insults and annoys them. Don't think just because there is no immediate measure like dropped-carts and churn that poor process isn't affecting your customers and your bottom line.

It's Ozone Day!

Someday I need to write up in detail what a total disaster transit systems are. I've had issues trying to figure out where I am going in other cities, or pay the fare, but assumed the system had some sensibility, and communications was the issue. Now that I have used my local system for a while, I assume they are all this bad, and are totally inexplicable. You pretty much cannot tell where anything goes, unless you already know. No one really wants to help, and the system is full of internal process and jargon, so communicating with any staff is difficult. But my favorite is that there are something like five different payment systems:

• Drop cash or coin in a fare box.
• Get change as a paper magstripe card, which you can then use in those fareboxes
• Get monthly ride cards, which are RF, so have a different system than the farebox
• 10-ride cards, which are paper, pass through no electronic system at all, and are hand punched by the driver
• Transfers work in yet another way, which I still do not understand

And the best part is that they are mostly incompatible with each other. If you have money on a change card, you cannot apply it to a 10-ride pass, for example. Today, all the busses say "Ozone alert" in addition to everything they usually say. You get on the bus and the driver says "you have 50¢?" To which most folks say "um..." See, there's an enviro/promo thing where if the city has an inversion or other conditions, they declare an ozone alert and try to get you to fill up your car after dark, and ride the bus. To encourage bus riding, they reduce fares to 50¢ across the board. Simple. Except for two things:

1. Not one person I watched board the bus seemed to understand what "ozone alert" or "ozone day" meant, when the driver said it to them
2. The 50¢ fare is, again, totally incompatible with most other systems. Your 10-ride cards and, apparently, monthly passes won't work. You MUST give them 50¢ or nothing else.

Turns out you can give them more than that and get a change card, or use the card, but the driver didn't seem to know that. Their internal process seemed to assume everyone in the city knows about this, and will being a pocket full of quarters to ride the bus on this, the most special of days. What assumptions are you making about how much your clients or customers understand your process?

Microsoft reorganizes oddly

Its not just me. I read this release about a change of the Mobile division yesterday, and found a lot odd with it. Later in the day, a whole spate of new promotions were revealed. Happy V-day, executives! And today, though it focuses on another appointment mostly this editorial, also at eWeek, starts to talk about how odd Microsoft's choices of leadership are. Since I am more mobile, we'll take on the new mobile stuff. There are two things out of this I want to cover. One, the new head of Mobile Communictions. When I saw the headline, I followed it to see which Danger guy was getting the job. Nope. Its Andrew Lees, from Server and Tools. Which means "servers." Maybe they expect generally good things, and maybe they need to work on infrastructure and deals, but I'd tend to say that the problems with Windows Mobile are at the handset layer, where your finger touches the screen or views the unresponsive pixels. (I'll also note that previous head Pieter Knook is appaerently already dissatisfied with all the fishing and rocking on the front porch of "retirement," and has taken a job with Vodaphone. Oh, wait, here's an announcement about Danger:

In addition, Microsoft promoted Roz Ho from general manager to corporate vice president of Premium Mobile Offerings. Ho will lead the new Danger team, which Microsoft recently acquired, and continue to focus on consumer-focused premium mobile offerings, the company said.

I'm sorry, the what? Premium mobile offerings? I guess Windows Mobile smartphones are not premium after all. And it makes me even happier at my comment here the other day. Could Microsoft try any harder to be insular as a company, and continue to silo their devices? I'm waiting for Microsoft to appoint a new VP of Interop, who jealously guards his domain and doesn't work well with anyone else.

There might be a problem with your business process if...

I promise I will not get into the UI issues of the ATM again. Well, not directly. Its prohibiting me from doing someting which I think I should be able to do. And, instead of prohibiting me, it throws an error after I have pressed 25 buttons and submitted little slips of paper. So, I'm annoyed. Its the one in the Hy-Vee (grocery) near the house. Maybe 15 yards (meters) away is a mini-branch. Its not busy, so I ask why.

No idea.

I mean, she was nice enough, but maybe I could get the question answered if I waited for the branch manager to get off the phone. I didn't wait that long. When chatting before I gave up I said something like "these new ATMs are much worse than the old ones, which were terrible."

Oh yeah, we hear that a lot.

So, in how many ways is this bank failing? 24/7 technology is emplaced immediately next to the face-to-face store, but:

• It has different business rules (not just technology limits) than the counter or website.
• The people have no idea how it works.
• And, they have no method of seeing what you did, or correcting it in any way (at least the terrible self-checkouts have an employee over-ride).
• The employees do get lots of complaints, and are aware there are problems.
• No one in charge of buying, specifying, customizing or installing the machinery has ever, apparently, thought to watch them in practice, or ask the people standing there every day their opinion.

Not to pick on my bank, I think this is totally typical of almost every technology implemented by a company. Even those heavily lauded for their experience, like Apple (ever tried to register the products online? and what is the point of dotmac anymore?). Netflix and Vonage are the only serious companies I know of that have any useful integration between their people, their product and their technology. And they are new, internet-only companies.