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.

I don't care, and neither should you

With a (briefly, before I leave this job) new UX manager, I ran into one of my other terminology issues. I enjoy saying we solve "problems," which bugs a lot of business people, as it implies that there are problems! Which is true to me, but I often have to say "challenges" or "opportunities" or other (frankly) bullshit. But today's special challenge phrase is "I don't care." What I mean is that "either of the two options presented can solve the stated problem equally well. I have no personal opinion." Of course, what people hear is "I could give a crap about your stupid company and this pointless project, and am just phoning in my work on this one." Of course, I am aware of this, so never use it in front of clients; it's an internal term for the design team, which I usually remember to explain first. Usually. Ideally, I'd have another term for this, so someone offer me one. Because, I cannot just say that I have an opinion on everything. This speaks to the core of every issue I have with interactive design today. UX/HF/HCI/IA/IxD/Etc. has become such a populist thing that a lot of practitioners are untrained, or poorly-trained, and even if experienced are unread and do not get the basics. Sorry, but as far as I see it, it's true. That leaves everyone to work their design the way everyone else nearby, in marketing and product development, seems to work their jobs: opinion, previous-experience, anecdote and whoever has the most political power. But I base my design decisions on my understanding of the scientific underpinnings. See how we laid out Designing Mobile Interfaces (on the web also); the patterns are typical interactive design communication. This works, and this other thing doesn't, because people might get confused... But the beginning of each chapter (and a lot of information in the appendices) cover why this is true. Cognitive psychology and human physiology underlie all of this. If you don't understand these, or at least trust people who do understand them, then you are not pursuing UX from an informed, repeatable point of view, and are just drawing whatever seems pretty at the time. This same philosophy is why we distrust market research like focus groups, and get strict about how we interpret usability research, surveys, and analytics. So, when I present or see two or three or five options for a design, once the obvious issues have been pointed out, I sometimes have no opinion. I have no personal opinion, and it needs to be up to the marketing intent, branding, visual design, or we need to make sure that there is no other secret requirement (e.g. unexpressed future needs) that can drive us to one solution or the other. There are plenty of ways to decide on one or the other, but if two options are equally valid solutions from a UX point of view, either look harder, or feel free to have no formal opinion.

This is what I sound like griping about pixels vs. boxes

For those few who have forgotten to remove me from your feed list, the absence has been totally worth it. Writing (half of) a 460 page book on mobile design was very interesting, and hopefully will be something important and helpful to you all. Buy a copy when it comes out, presumably in a few months. Last year I was on a panel with, among other people, Luke Wroblewski. He was "defending" his then-new concept of mobile first. I was supposed to be the naysayer. But it takes me a while to warm up to people and be abrasive, harsh and disagreeable, so I ended up looking like I agreed with him. Everyone else did, so it was a rather boring panel. We're sorry it wasn't exciting. I did agree with the principles – which I'll get to eventually – but I didn't fully understand how much, or even really why I disagreed with the practice at the time. At the time, I thought I had a nice cynicism baked in, but in fact I'd worked in or with organizations that more or less bought into the concept of UX practitioners and let us do our jobs. Some encouraged it. Since then, I've had to leave that job, and as it turns out that whole world. Not the design world, but the happy design world. Before I go further, I should mention to anyone who works with me, you may or may not know what I am talking about. I have a day job which is separate from my freelance clients, who don't know each other. Though it probably decreases my ability to network and sell, I respect client wishes and do not generally even imply who I am working for. I also have friends, and keep track of former co-workers, and talk to others about their new jobs. And with the writing I have been very much keeping up on the world of mobile (and other interactive) design. So if this sounds like you, and you are offended, there's probably someone worse, or at least it's a composite. Don't get in a huff about it.

It's like I never left

I'll hope we can all agree that the end goal is good, useful design for the end-user, and the way they work. But from there it all falls apart. Let's get right to the heart of the matter. A lot of people use this as the basic unit of design, for all interactive work: I see it used by those who distribute involved raster PSD templates for designing on a specific device, or write up long explanations of how to use Fireworks for mobile design, or who push or promulgate pithy catchphrases like "mobile first," (or "CLI first") really. They often routinely conflate interaction and interface design, or just call themselves "designers" without distinction. Many work at companies who hire designer/developers, or cannot fathom what a designer does if not also writing code, or at least prototyping everything, as soon as possible. Yes, I am enough of a taxonomist to know that generalizing results in generalizations. I don't much care about individual cases. But if you want to talk specifics, I have seen at least three well-meaning, otherwise mostly-useful repositories of information refer to 44 px as the right touch target size this year. If you are not horrified by that, turn in your HCI credentials. You may have noticed that people cannot be measured in pixels. So it was dumb a couple years ago when there were too many Apple fanboi designers. But now even iOS has multiple resolutions. Saying "44 px" without caveat, in 2011, should be tried in the International Criminal Courts at the Hague. It all reminds me of 1999. That's when I started seriously – in front of clients – rejecting the concept of the "page fold" in web design. By way back then even the desktop was becoming too fluid or fragmented to pick a screen size for everyone that was the same. Anyone who starts with a single resolution for mobile is fooling themselves, and wasting opportunities. Without over-emphasizing the point, designing in pixels is dumb. Anything that reinforces or just trys to improve designing in pixels is also dumb. Note that I didn't say we don't need Photoshop. It's open alongside InDesign all day, every day. And I in no way said we don't need visual or graphic designers; I have an art degree, and have won awards for digital art and illustration, but it's not my day job today, and I need that sort of designer to collaborate with. I said "designing in pixels" is bad. Don't over-reach and miss the point.

So, what's your point?

My basic element of design is this: I like words also. If I can get them, well-formatted bullet lists are nice, but if I have to just boxes and words will do nicely. Two pixels together are two pixels. But two boxes together are nested. or adjacent, or overlapping. They interact. They can move. One can conditionally disappear. Don't even get me started on the possibilities offer up by three boxes. The mind boggles. What size are they? It doesn't matter. Or: it depends. On rules we don't just assume, or constrain by declaring a resolution, but by determining some what size and what items stay on each page in which position as the design progresses into addressing different platforms, different devices, and different aspect ratios. This is all based on every other type of design or drawing or illustration I have done or learned. You start with basics and move into details. You start with sketches and settle on aspect ratios, orientations and sizes. Details get filled in as it evolves. So few artists start their work at full detail in one corner that it's generally studied as a condition. Whereas I have seen an awful lot of interface designers start by laying down a gradient bar at the top of the page, pick the color and type the title in, then proceed from there.

What catchy phrase can I use to remember this?

My mantra would be something like "do your job first." Yeah. I am not that great at catchphrases. But I still believe in it. Don't jump to final designs, and don't jump to even wireframing of any one platform and resolution. Let the process unfold. Analyze existing products. Ask clients and customers, then build goals and objectives. Put Post-Its on the wall, then start drawing. With whiteboard markers, and sharpies. Eventually you get to make boxes and they evolve, and branch to the needed interfaces. Doing it all like this might even help you identify which devices and modes in which it should operate. And remember to design for people first. I once was in a meeting at a Fortune 50, who had hired a respected and well-known design firm to do some interactive design. They brought some "mood boards." That's what they called them, but they were single images just ripped from magazines and blown up. Starting your design by copying the last thing you did, the standard OS template, or the coolest new thing, locks you into that first pretty picture in the same way, and everything will be a variant of it, instead of your own design. Let IAs do IA, let Information Designers design the information, let IxDs design the interaction, and yes let the VizDs do everything they do to assure it's all tied together as a cohesive interface. Respect all the jobs, and don't fall for shortcuts, but do your job first, last, and always.

I wish we had a manifesto

If this strikes you as totally the opposite of the way you work, rest assured I am not just some nutjob screaming in the wilderness. I've worked with or for plenty of others who believe in this. There are whole, large, respected organizations who work like this. Ones you've heard of, and who are too cool to hire me. But we all spend more time doing our work, or arguing with each other to get together and realize our similarities and write up a public, non-proprietary process to get noticed. You, no matter who you are, probably believe at some level also. Ever done a whole design session with just sharpies and Post-Its? Ha! I caught you. Try that for a few more layers of design and see what happens.

You probably shouldn't listen to me

I mentioned up front that I can be abrasive and disagreeable. If you don't think so now, you haven't been reading closely enough. I get along with a lot of people well, but (I have been recently told) not always, not with everyone. Don Draper (and his ilk on every TV show) gets away with a lot more than I can, or you probably can either when selling to the client/patient/judge/etc. The right idea doesn't always win out in the real world, so even if you are ready to join the revolution and start that manifesto, you need your day job still. Be ready to lie to keep the clients. I do this all the time. They want to see the home page, so we make one up, with gradients and icons and banner ads that are better integrated than they'll ever be in reality. Then we ignore it (rarely does anyone keep them around) and get back to developing the design the right way. I am sure some people are bugged by the morality of this, but I certainly think the end user and the end deliverable is still more important than a short-term deliverable. I am willing to stretch the truth a little bit. It's in everyone's best interest.

Does it Fax?

This is an old phrase used in logo and brand design. It meant that you need to keep in mind how that 7 color process logo (looking at you, Apple Computer) looks not just one color, but when stretched, muddy and generally screwed up by fax. But it also became shorthand for keeping in mind how it works in anything sub-optimal. How does it look in newsprint? Or on TV? Sadly, on places like the Brand New blog comments, it's now moved to a joke. "Who has a fax machine" they ask. I say, way too damned many people. All sorts of financial institutions still use them. But more importantly is the meaning behind it. It used to be that every logo was designed as a one color exercise. Black on white. You made a shape, and made it perfect. You could (and should!) also make color choices, add gradients and decoration as appropriate, and generally design it as part of a system. The perception that everyone has a high resolution digital display has slipped into logo design being a single-point exercise. Its made to look good comfortably large on the computer. And that's it. Applications are maybe adding different type to the logo for the branches of the organization. Or by adding animations. But I still ask, basically, "does it fax?" What's it look like on a badly calibrated monitor? How about tiny, on a phone screen, in glare? How about as a logo in the corner of a crappy TV screen? What about as a favicon? What if your client prints your tabloid documents letter sized, then photocopies them? Does it look good then? Brand is an often forgotten, but key part of developing relevant interactive design. Every part of the brand matters, and if you give me a crappy logo, or no guidelines for implementation, it's not going to work well. Online doesn't give you a pass for making good branding.

Working Agilely... With Agile? Whatever...

I talk a lot about working with other teams, satisfying the business owners and making sure your work as a designer is consumable by implementation and test. But when I started typing a response to this question on a LinkedIn group, I realized I hadn't really gotten tactical enough in some of it.

The basic question is a good one, I have answered many times internally. "How should UX work within Agile development processes?"

The common refrain from other UXers is to follow Jakob Nielsen's suggestions on the matter. But I find that doesn't work well at all, actually.

I've worked on several dozen (large scale) serious Agile projects and have developed ways to make UX work within them.

First: The IT process gurus they hire are, not to put to fine a point on it, idiots. I have asked such pointed questions of them in kickoffs they were fired and never came back. (Yes, there are also good process guys, and I have actually worked with some to develop the processes below. But process consulting has grown too much in the past 10 years or so and will put anyone through a 2 week course. If you are a process guy who is offended by this you are not a good one, or you'd be annoyed at your many awful colleagues.)

The key problem is that everyone who loves Agile likes to conflate "iterative" and "incremental." Look it up. It's scary. What it means is that a LOT of projects are Agile in name only. They break up development into Sprints, they have their daily Scrum, etc. but the end result and the day to day work is the same as it always was: developers go off, write a piece of code for as long as it takes them, never come back and add to it again, and just toss everything over the wall to the next team. Waterfall in all but name.

But let's assume the process is practiced correctly and is not a bad choice. By the way Agile is practiced even correctly, design is rather left behind. The best that can usually be hoped for is something like this:

You can see Design phase, but they are for software design, and are far too late and constrained for user experience teams to influence the course of the work.

A common retort is to have UX help in the planning phases, and be deeply involved in the iterative design phases, but spend at least half their design time each week working on the next iteration (if iterations are longer than a week, just replace the word “week” as needed).

This is the version where UX gets to do their work 1 iteration ahead. It is clearly wrong. It never works in practice because you end up working on the current and next iteration. Not only is there not nearly enough time to do the work, but it leads to methods (by PM, IT, and you) of solving today's problems, and having no holistic view.

Really its... okay. I’ve done it, with measured success, but it’s not truly satisfactory.

In fact, when I worked previous model and evaluated success (when I talk about whether process works, I mean it; I actually do AARs and run stats on my projects so know when things work or don't), I eventually realized I had a bug in the data. The best part of the results were from the early planning I helped with.

In Agile, two things are pretty solid, from the original planning: the timeline, and the original plan itself. The list of features is completed in week zero, during that planning phase. Many software design documents are completed here, and are almost completely stuck to throughout the process. So, what’s wrong with just adding UX deliverables to this?

As it turns out, a few things. Even there, IT definition processes can get ahead of design and business needs. UX design needs to make their basic plan during the phase before this when business requirements are being developed (and even help make them). Then, additional details of interaction design, fixes, and guidance can be offered throughout the rest of the process.

So I added time to the process! No. I didn't. Agile is not a project plan, it's a development process. There's other work before Agile exists, and I just say you need to get involved up here. Yes, I reframed the question. Tricky, aren't I? Anyway, months earlier is ideal, but I'll take a week if that's all I can get.

Note that I’ve make UXD (and IxD) a whole new bar in the chart. That’s because the holistic view and the work on multiple tracks mean they work more at the PM or business owner level, and work with – but not within – several individual phases, all at the same time.

If you think this will be hard to sell, read up on the process again. If you approach it right, and use their terminology, and offer to help with Sprint 0 deliverable development, you can sneak this in, effectively. You aren't adding anything to the process, but are complying with the original Agile intent much more than by trying to shoehorn UX into each iteration. Process guys will sigh when you introduce yourself as the UX guy, then love that you are just gonna work in their process and not insist they add time or phases.

What about user testing?

Okay, one more thing is that you can still do iterative evaluations and fixes. But not as much as Nielsen's article would have you believe. Agile projects rarely push something usable with every iteration. If you attend the planning meetings, you can figure out which ones are big, can make friends with test and get access to the test site to run people, and try to get some feedback during the project.

What can you do with it? Well, I say not much. If it's more than minor, then you will want to change stuff that is architectural and that's planning or featureset stuff. That's hard to change on a dime (maybe XP can do it, but we're talking Agile). Usually, I just gather the data, analyze it, and only raise issues if they are critical enough I think it's worth arguing for more time. Otherwise, I go to the product owner and make sure we can have a second phase.

The closest this gets to ideal is that there are a handful of phases with unassigned features at the end, and whether it's after the initial launch or not, you can go off, make your revisions, and get them slotted into these last phases with the same team as a rapid maintenance release. This can work, but you have to know the process, and be able to talk the language to make it happen.

And in case you haven't figured that out, if you get in early enough, you can do the normal design process stuff, and take months to do competitive analysis, do needs research, come up with paper designs and A/B test them, or whatever makes you happy.

Regardless of the development process, I say the greatest benefit UX can provide is the moment after the project is a glimmer in the program manager's eye, or when the data comes in that implies a revision/improvement is needed. If integrated well, or engaged at the right time, UX has done a lot of it's work before any IT Dev process has even begun.

And I have successfully done this many, many times.

If those diagrams above are too small, you can get a PDF of them if you'd like.

Influencing the Requirements Process - Designing Documentation, Part 2

Specifications are hard. There are a lot of conflicting needs, and the complexity of the documents might be more severe than the product you are specifying. Aside from designing products or interactions or interfaces, I spend a lot of time designing the documents themselves. A happy ending to this sort of process is detailed in last week's post on Designing Requirements Documentation.

Which might bring up the question: What type of specification? Design documentation, which is most of what we do (well, by hours – most actual documents by count are proposals and emails and so forth) took a long time to settle on, but it has evolved into something pretty specific and which works very well to communicate to everyone on the entire project team. There have been several evolutions, many mandated by technology alone; I used to do everything as a single sheet which functioned as sitemap and flowchart and detailed page/state layout. But when I had to work with more remote teams getting 36" x 10' pieces of paper to them was more difficult and had to change to something else.

But complete technical specifications are still something else. There are also content specifications, style guides, and lots of other documents. But today let's talk about the general technical specification, that developers use to build or modify software or presentational code to meet your design needs. Integration of technical specs with design has always been an issue. I've spent a lot of time messing with my deliverables to make them comply, or revising them to be pasted into the appendix of an IT specification. All of which is fairly unsatisfying and never helps much.

It is also important to believe that design documentation is good, important, valid work. We spend a lot of time buried in IT process, and I have to fight even people here at Little Springs to make them believe that our work and our method of work is valid. Sure, you can use IT requirements documents to do your work, but that's not their intent, and there are better ways to do it.

After a lot of work imposing myself and my team into the development process with our own documentation, way back around 2002 – while working at Sprint, I got to work my design documentation directly into the technical specification. At the time, Sprint IT used something called Application Design Documents, and I was able to persuade them that the UX team could do the best, most efficient job of making some of the document.

Note that the text and tables are in the IT format, specifying the behavior of each widget in a specific manner. And the screenshots (I prefer other methods, but this is what they could handle at the time) are placed in a process-compliant manner, but there are just about 20 times as many as usual. I also did a lot of the writing, or at least editing, of the specifications, so when it was done both the IT analyst and the whole UX team agreed on the behavior of each and every feature.

This product, both by design and implementation, was a high-water mark in ease of use in my career. Web-initiated SMS with millions of uses a day, without a help system and hardly any error messages, with impossible uptimes and no measurable customer complaints. Almost unheard of for a mobile telecom operator, at least in the US. And although it took forever to create the document, some of this was simply getting everyone involved used to the new process, and we saved a lot of time correcting errors and explaining stuff in development.

But then that dream died. After a few months of work, a big fire-everyone-for-IT-outsourcing binge left disappointingly few software designers and analysts in house. I had to start all my relationships over and reconsider how all deliverables would work with random, far-away teams using them. So for the next few years I made do by improving my design documents, communicating with project teams as much as possible, and actually writing requirement documents when I could.

Writing requirements

Which became a key task I tried to accomplish. If the UX team got engaged early enough (which is always a problem) I pushed to review and approve the requirements. Then I found out no one wants to write them, so simply volunteering gave the UX team lots of additional authority.

A key reason I like working on requirements is that they are often poorly done. For example, Business Requirements and Functional Requirements are too often conflated. A BR document is very, very high level. It contains the goals of the project, and rarely more than a couple dozen, or that's a sign you either wrote them wrong or the project is too big to be completed. Some Business Requirements you might read are:

• System shall have the ability to allow user to enter a street address and geocode it to a dynamic map displaying coverage and signal strength.
• System shall have the ability to drill down from a national map perspective if no address on file for user (i.e. in-front of log-in).
• System shall have the ability to allow user to enter only a ZIP code and geocode it to a displayed map.
• System shall have the ability to allow user to enter an intersection and geocode it to a displayed map.
• System shall have the ability to allow user to enter a City/State combination and geocode it to a displayed map.
• Etc.

But this is dead wrong. System? And so very many. That's a set of Functional Requirements, and not a well-written set at that. But all is not lost. Assuming that the marketing and product people like these, you can redo them as actual requirements. A typical, well-written Business Requirement could read:

• Allow customers to find coverage for a specific area in multiple ways: by entering a general location, a specific street address, an intersection, two locations, etc.

And this covers all those bad requirements above, and then some. Cases you don't think of at the beginning of the project are still in scope. A half dozen more like this and you have a project.

Functional requirements

A Functional Requirement on the other hand provides specifics of technical, logical, or presentational behavior. These are also boring, so often don't get enough attention. Oh, they have to be written to proceed through the IT process, but no one wants to do it, so they get poorly written. If you want to make sure the product gets built right, and that the implementation teams are doing what you designed, just insert yourself in the process.

Good Functional Requirements look like this:

FR-40 From within the Wired Web unified messaging access portal, a function will be provided for customers to move SMS messages between folders, (e.g., Inbox, Outbox, Spam).

Better written Functional Requirements help a lot. Some notes about requirement writing were in the earlier blog entry, so I won't repeat them here. But they better not all start "System shall" or "Ability to." Even if it's nerdy, academic, and technical, with otherwise annoying neutral-voice characteristics, use good english, first and foremost. The above requirement is written the way I like them all to be. First, the condition or state From within. Then, who can do it, here the customer, but the system may automatically do things at certain times or when certain conditions occur. And then, what happens. Pretty generally. An example of the folders are given, but there's not a requirement for each folder, and a comprehensive list is not given.

Not just because this would be cumbersome, but because it would be wrong. Remember, there are other documents and other requirements. The structure of the folders here is likely described in some architectural specification. So as part of this writing, be sure to understand the scope of the document, and how it works with the many other documents that are part of the IT process upon which you have imposed yourself.

The product is more important than you are

And after all that, it is a bit thankless. Your name will probably not be on the document as an author, and everyone will credit the analyst, who may not credit you. That's fine. Often, it's preferable, since UX is viewed with dark suspicion by parts of the organization.

Even as a vendor, we pretty often deliver work in someone else's template (or, have to create one that looks like the client's brand).

Getting the product right is most important; work on how your team is perceived later. Which is probably a good topic for another post in the future.

While I won't be hosting a process workshop at this year's Design for Mobile conference, there's plenty more to learn about mobile design, technology, strategy, research and implementation. Still some space available, so join us in Chicago next month.

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.

Design of dials and doors

Check out this control setup in a new Ford truck in which I was recently riding: Ford has, thankfully, gotten out of ovals everywhere design, and seems to have replaced them with circles everywhere. Note the five actual dials below the radio controls. The far left one is the drive system (various 2 and 4-wheel settings) the center are the HVAC controls, and the right is... what? Seriously, I wasn't sure at first. 12v is the only position labeled. So I try turning it. No movement. Pretty rapidly it becomes clear it's not a dial. Tug on it (carefully, in case I am wrong) and it's a hole, a power port. In the past, this was the cigarette lighter, but now it's a power port. The only hints it doesn't turn are a little depression to the right, and a lack of an indicator line pointing to the "12v" setting. But the overall style embodies the "rotary switch" meme. What am I supposed to think this item does? I know exactly how this happened, too. For pretty much my whole career I have had to deal with the same issues. I don't know what it's called in industrial design, and even within interactive, names vary. "Visual design" is the most common, I think. Visual designers are tasked to add a style to the product. Usually, one that reflects the overall corporate brand, but always their mantra is aesthetic and consistent. My problem is when they try to common, universally-understood, design language with another set, in the name of consistency. This is a great example. Aside from communicating "rotary switch" vs. "hinging cover," I would consider there already is a design phrase for "power port." It's a particular knobby style, descended from the auto cigarette lighter itself. Within interactive, the most common cases are trying – or needing – to replace standard controls, like scrollbars or form elements. Either a stylistic change is desired, or something like Flash is used to create a large portion of an interactive element, and the design is proposed with non-standard checkboxes, or scrollbars that don't work by click-to-position or dragging. I have actually sat behind the mirror and watched such items fail users. For any designer, of any interactive element, consider the value of your design contribution. Is consistency of visual look more important than instantly communicating interactivity, and meeting user expectations, through use of well-known elements?

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?

Why does this switch exist?

Wal-Mart has by far the best price on propane, so I'm there with the rest of the fearful masses buying stuff to survive the impending storm. Across from my lane one of the cashiers is closing down, and keeps having to tell people to move along. At once point I hear: "Lanes 9, 10 and 11 are all open... though John hasn't turned on his light yet." And my cashier hits this switch: And it occurs to me that I have always wondered "why?" The register is already a piece of powered equipment, has been for well-nigh a century. Generally, the operator has to enable the device; now by signing on with their own credentials, but in the past at least with a key. So, why a separate switch? Why not just have the light come on when the register is in "ready to accept transactions" mode? Sure, I can come up with cases where the register is being used for administrative tasks, but that's an exception, and an over-ride can be provided I guess. But the primary case by far is being missed, badly. Now, off to brave the ice weasels.

Process, procedure & methodology

This entry is also posted at the Little Springs company blog. If you feel compelled to comment, I'd do it over there as its quite a bit better read. Interactive design is exactly like making a pizza No, its not. At all. Its also not at all like building a house. Or changing the tires on a car at 60 mph. Or any other favorite analogy your leadership has used to describe the situation. Sometimes, this analogy work goes quite a bit too far. Inappropriate analogy – or blindly inherited process – encourages inappropriate process and methodology. Houses need blueprints, then foundations. Do websites? I think that considering design and code to be “construction” leads to incremental approaches and a misunderstanding or misapplication of iterative design, for one example. Its time that interaction design (and software development) comes into its own, and can be understood without arbitrary analogies. To that end, what is a design process and how can it be applied to design work? Process – Making the business work Process is about business practices. How to get business, how to account for time spent, how to assign people and so on. Some of these will be performed by the design team. You are likely to have internal staffing processes, for example. However, since they are about internal functions, not design, they are business-oriented, and are process. Processes are also enterprise- or product-wide. Everyone has to abide by the same process or it won't work. If a strict set of rules can be applied, but the result will change over time, or as internal conditions change, it's a process. Think of scheduling new work; any designer (ideally) should be able to do the job as well as any other. Which one is assigned is dependent entirely on workload, scheduling, and generally internal and transient conditions. The conditions of the designed produce have little or nothing to do with it. Procedure – Working with others Collaboration requires everyone be on the same page. The quickest way to this is to make sure everyone does their job, and communicates, in the same way. The difference between process and procedure is that “doing stuff the same way” part. Procedure is needed for any workgroup large enough to warrant a process. Not only does the process need procedures like paperwork and meeting times, but each functional team will have them. The process for design teams will include artifact creation styles, storage, sharing and other collaboration-related functions, within the team, with clients and with consumers of your design work. Other departments will have their own procedures, by the way. Work within yours, and be aware of others' but try not to confuse them with process. Methodology – How you design The manner in which you work is a method. When this is repeated and codified and applied uniformly it's a methodology. Since we're talking about design, methodology is about activities and artifacts directly related to the design work. Good methodology is about designing well. Since this is our field, I can go on for weeks about design methodology , so I won't do that. Yet. Your next steps Internal process, procedure and methodology are easy. Everyone in the design organization should believe the same things. The hard work will be with the other groups, the clients and the developers. Build your relationships and sell them on the right process. Keep in mind:

1. There are good processes and bad ones. Push for recognition of which process is being used, and for using the right one.
2. Get the terms right. Know what you mean, know that everyone understands you, and make sure they know it well enough to explain it later. Likewise, if there's any question about others' terminology, ask for clarification.
3. See what happens. Once a product has launched, did the right thing come out the other end? Either way, why? Find root causes and implement fixes. Don't let everyone skip this step because they don't want to be confrontational or just want to move on. Otherwise, nothing will get better.