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.

Stop that desktop thinking

Since all my employers are east coast, about six months ago I stopped changing my watch every time the plane landed (or took off... I never could decide which) and just leave it on Eastern Time. And I am comfortable with this. I just have a part of me always out there, and then adjust the time in my brain. Not a big deal, really, as I do lots of stuff on 24 hour clocks and am adjusting the readout in my brain anyway.

I also asked a friend who was formerly Air Force special operations, and he said when flying about the world, you just leave your watch to UTC, and know where you are. But that's a watch. It's deliberately an old, mechanical item. Mine is specifically one of those that winds itself as you move about, so as cool as an iPod Shuffle watch would be, I don't have to worry about it failing to synch, running out of batteries, etc.

Okay, now, tell me why my laptop is always set to Eastern Time. Better, why should I have to change it myself through a control panel? Why, if I do change it, do a series of applications yell at me to find out if I want to change the time zone within themselves, separately? I think it's because of something I think I'll declare Desktop Thinking. Desktops are dumb. They are shiny and "easy to use" but are just a few generations from terminals, used to access the unfriendly mainframe, and there's still this same mentality. The user will perform operations, the machine will respond when it feels like it. The user requests information, or to begin a process, and the machine starts doing it. But not a moment beforehand.

Embracing mobile, on the other hand, means you think about information the user needs, you don't ask for information you already have, and you don't throw away anything the customer entered or might need later on (within the constraints of privacy). Google Calendar is one of those tools that (at least on the website) incredulously asks if you want to change the time zone. Apparently, they are of the mindset that changing time zones only accompanies selling your house and moving across the country. Whereas even this typical desktop website, just for one example, takes a stab at determining my position, and defaults the information to that region.

Which brings up, believe it or not, some thoughts on location I touch on in Designing Mobile Interfaces. How do I set my watch, or make sure that my laptop is in the right time zone (or that it's set right with Daylight Saving changes)? More often than not, I consult the clock on my mobile handset, of course. Location only needs to be as accurate as it needs to be. If you want a weather report – or to know what time your meeting starts – there's no reason to turn on the GPS to find out where you are. Very rough location, often just to within a few dozen miles, is just fine. But it needs to be there. Don't disable functions in favor of only offering the highest precision. If an approximation is good enough, or faster, use that.

This is some of the stuff I am talking about when I say that context matters. And when I say that it's not the same as user intent, or user goals, the physical environment, or whatever else you might want to use to replace the notion of "context." I mean that the device should be intelligent. And as much as I like – say – Siri's way of being aware what you just did so the next task is more useful, I want it to do more. Something as simple as knowing what time zone I am in, and reacting appropriately to that is what you might call pre-emptively contextual. And now that I write it, that sounds great. Mobile tends to do this. Sure. But only at the most surface level still.

I think a lot of apps do this just because they get the time from the handset. But I still see Desktop Thinking during web and app development, even on mobile. The user will sign on. The user will pick a link. Even just: once the user clicks our icon and launches the app. And often I ask, why? Why can't we make a widget, or a notification that lets them launch the app when we tell them something neat has happened, or... anything that predicts and offers information at a glance, or helps the user when they didn't even know they needed it? Think about not just your assigned silo, but how your user can get real benefit from the information, intelligence and processing you have available.

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.

4ourth Mobile is a Thing Now

Long before I had a day job, I freelanced. I did design work when I was in Junior High. Actually, I recall that first paid job (sure, my dad worked there) they weren't happy with the results. Probably worth thinking about more and writing a whole post about how early failures made me the type of conscientious designer I am today. Later. I've made over half my income some years from freelance or contact work, and while it petered out in the past few years, when we all lost our jobs a year ago, making a virtual agency seemed a natural. I've been sorta calling the freelance work I do since then part of the 4ourth Mobile brand, and the Designing Mobile Interfaces book Eric and I are writing has a strong online presence at a wiki under that same site. But I haven't really marketed it in any particular way. Well, now I probably should get on that. Yeah, maybe this is old hat for everyone else, but I've never actually bothered to incorporate anything before. I just faked it, filed a Schedule C and made do. Accountant friends forced my hand here for tax reasons, but really it's a good idea. So, consider this the official announcement: 4ourth Mobile is a thing. Call it a virtual mobile design agency. If you think well of one of our tweets, or blog post, or The Big Book of Mobile Design, contact us. We can do training, or design, or user research, or just chat about your needs and see if our concept of a mobile strategy is the same as yours. We're even multi-national, and can travel, so whatever your needs, ask and we'll talk about it.

Sample page from Designing Mobile Interfaces

We're all the way to QC1, which means Quality Check, as I get it. I think there's a QC2 in a couple more weeks. It's tedious work, but also thrilling to see it not in Word, or on the web, but actually in a book format. Enjoy: And don't forget to pre-order before it comes out in November. Now 560 pages, but Amazon shows much less than that. I suspect you will not be able to get it for $30 when it comes out.

The most interesting thing about the Kindle announcements

I found Amazon's announcement Wednesday to be very interesting. Almost unexpected. And I don't mean the Fire or Silk parts. Or the pricing of the Fire. What I found really interesting was this: Yeah, just the line of new products. But that's it. A whole line of products. A new low-end, improvements to the e-Ink, removal of the keyboard (more on that later). Not just retaining the old models, and maybe lowering the price, just to appeal to cheapskates. You'd think that based on rumor, and pretty much every other review or comment coming up to this, or today.
A key reason I like seeing stuff like this is that it continues to vindicate the scope of Designing Mobile Interfaces. A year ago, when Eric and I started writing it, there was lots of discussion about how much we'd focus on iOS. "Um, not really at all." So, also Android... And Blackberry? No, there are plenty of those sorts of books. We made a mobile design book. For all of mobile. Check out this pattern on Keyboards & Keypads for one example. In there we talk not just about the best way to make a touchscreen keyboard (and we don't just say "do what iOS does" but also hardware keyboards, also keypads and triple tap, and even scroll-and-select virtual keyboards. Wait, why does that sound familiar? Not just because my PVR does it, or my GPS, or I examined a lot of products and it's just a way to do it, not that... Oh, yeah. Because the new low-end Kindle uses that exact system. And why? Hell if I know. I don't work there. I'd guess that they found people don't type as much as expected. And it helps make the price point, and so on. They don't do this stuff randomly.
And that brings up the point you actually care about. If your mobile strategy is to make an iOS app, or you are updating your product to have a color touchscreen, and you abandoned the old way, you are probably doing it wrong. Amazon is not good at everything, but they are pretty good at some stuff. And selling eReaders is one of those. I am not the sort of designer who takes everything Amazon (or Apple) does, and slavishly copies it. But Amazon is a mass-market success story, and with the Kindle they had amazing success with a pretty new class of product, which they are clearly trying to make available to everyone possible. New technology doesn't always have to be expensive, new versions don't have to be cutting edge, and the low-end is a huge market. Are you focusing on the bigger market, or just what you think is cool? If you like everything I said, and think your product needs some thinking like this, maybe we can work together. Go ahead and contact me about it.

Interactive Criticism and the Cult of Clean Design

This discussion of minimalist posters got me thinking of some of the design problems I have been encountering lately. And that got me to thinking that I have been seeing a variation of this for years and years.

 Unlike much of the graphic arts scene, it seems that interactive design hasn't gotten over it's trend of simplicity and whitespace for their own sake. If anything it seems to get worse year after year. While I won't quite blame Apple – and everyone else who follows that design ethos of spartan minimalism in everything – this is the design I am talking about.

 But the problem isn't really that we're stuck in a design rut. We are, but it's much more that not everyone evaluates everything the same way, with the same depth. People use a cool new product (on their iPad), then come to work the next day and say we should make a product as clean and easy to use as this.

 But "clean" and "easy to use" are different things. In the same way that "look and feel" are two different phrases (hence the "and"). "Clean" rapidly becomes misinterpreted as "low-featured." "Easy to use" becomes misinterpreted as "easy for every single person in the world to use." "Simple" turns into "simplistic," and we cut features not to get to core principles, but because they are visible.

We cut features not with a knife, but with an axe. And rapidly, any feature is worthy of being assailed not on it's merits, but on it's immediate visual appeal in a wireframe, or comp. But it's a false argument. Anything, – anything – can be assailed as cluttered, complex, or any number of adjectives that are, really, meaningless. There is no way to argue against "you don't want to confuse the user..." on it's merits, because there is no internal logic to this argument; it has no merits, really.

I routinely want to challenge such arguments and bring us back to principles, or to the scientific underpinnings of the practice. "Hard for which users?" or "But this feature is required to meet objective 2…" or "But the research proved that 100% of the participants prefer…" So maybe we can win the argument by counter-attacking their premise, and getting to the core of the issue like this. At least on the face of it.

Because really, we're missing a key point by calling it a design issue. It's a communications issue, or maybe (as Alexandra Lange responded in the comments on that Design Obsever article), an issue of design criticism. I admit that I would not have made any of these connections without her article. As practitioners of IxD, UI and UX, we try to make decisions based on provable knowledge. You could even characterize it as a scientific approach to design.

But it's not always true. Opinions still abound in discussions amongst ourselves. About interpreting what actually happened in a test, or what situation we are really looking at, so what heuristic should be applied. If you were to watch a design (or art) critique session, you might think it's just a conversation, but really this is a fairly formal construct, with rules that make it work to everyone's advantage.

You cannot complain about a work without merit; "I don't like it" doesn't fly. You better have a good, reasoned argument as to what you don't like, in what manner you don't like it, and maybe even suggest a solution. It better address the intended audience, or the purpose of the object. Assuming use outside of this may be irrelevant.

 As the creator, you better accept all criticism, and I don't mean passively; you have to engage in the conversation, to make sure everyone understands each other, and so group discussions can help reach consensus on the best course of action. Note that I didn't say "solution." One individual still ends up cutting the wood, or painting the line, or placing the pixel. Iterative critique gets it closer to the intended goals. Mostly, you cannot perform design criticism alone, or as the only proper practitioner of it; everyone has to participate and follow the rules. 

 Interactive design doesn't have any of this. Sure, your studio might work fine. And I have absolutely been on teams – or led teams – that worked exactly like this and had terrific group design critiques (and terrific products came out the other end). But as a whole discipline we do not have a method of critique. We argue, cajole, express opinion, refer to previous solutions, and our favorite products. We make deals, and end up splitting the difference so we can stop arguing and get to the next point. We decry ornament (especially when we bow to the altar of Clean Design) and insist we evaluate based on interactivity and process.

All while we draw comps and complain about crowding objects, and demand white space be added or everything align to the grid. We carry out common practice, and build what is easy, instead of finding and defining what is truly, demonstrably best practice. We do not share, or tell anyone else about our design solutions. Maybe not even the guy in the next pod, but almost never to the design community as a whole. We design in isolation, take criticism as insults to our work, and believe there is design that cannot be improved upon. We perceive openness to opinion, fuzzy concepts or acceptance of change as weakness. We are simply confused (and maybe assume it's a trick or insult) when a designer offers to change to an alternative design when a good point is raised by others. And we cannot fathom why our clients do not respect interactive design and user experience as evidence-based, consistently-applied, professional fields, and express sorrow every time they insist we change something based on whim.

 We need an ethos of design criticism. Not a process. The existing ones for fine art and design work fine. And we must not stop disagreeing with each other. We must not stifle creativity, or reduce iteration, or work more in isolation from fear or as a res Of course you know that arguing with the client never really works. I said that up above because that's what I want to do, but another approach is needed.

 So, if you agree, what next? Well, it's simple. Do this. Tomorrow. Okay, it's the end of the week. So, Monday. The next time you bring the team together, lay out the ground rules and tell everyone this is how we're going to talk to each other. In several ways – but especially in becoming a seasoned practitioner of art and design criticism – going to art school was maybe the best education I could have gotten. I've been thinking for a long time we need to teach not just what you should know, but how to do it and how to do it with a team. Not every field of study or school does this. You can make sure to teach your junior designers the skills they need, and not just assume they will pick it up on the way. And you can try to get the right feedback from everyone.

When you walk to someone's desk, and they give feedback, ask them to justify it, very precisely. Nicely, but get to the heart of it. Anyone can answer these questions if pushed to it. Not naturally, but they can. Even your clients. If you are told "why not more like how Amazon does it?" then pull up that part of Amazon, and ask in what manner this solves the need. Ask how this meets the goals of the product, ask questions you know that there are answers to, or which they will enjoy answering. As much as it's been talked about, there is no certifying organization for IxD.

As much as some people get to write books (now me!) and get followed by thousands of people every day, there is no one guru who can change the whole field. We all do it, every day, as we work with each other and improve interactive products. If you like this idea, do it. If you have a better one, do that. But if anything ever bothers you about how our field works, talk about it, find a solution, and put it into practice. This is how we improve ourselves, and our little part of the world.

Context always matters

It has become fashionable for a few months now to say that mobile is so ubiquitous context doesn't matter. I've even gotten comments from technical editors for the book Designing Mobile Interfaces to this effect. So, I've put some thought into it lately. And it's true, people use their mobile devices at home, in the office, and other "not on the go" types of situations," an awful lot of the time (some surveys: 60%). However, there are a couple problems with saying "context doesn't matter." Because the manner in which people use things /always/ matters. And in fairness, at least few of these folks are in fact referring to the way users always matter, but I argue that this is the exact same thing, and there's no reason to change the way we talk about things. More importantly, the old mobile context discussions never meant just "on the go" in the sense of "on the bus" or "walking down the street" to the exclusion of "in front of the TV."
A key reason I think context is still a good and important thing is that it's not just good and important for mobile. Personas are often the closest we tend to get for desktop design, but if you think hard about these, you'll find that some of yours include contextually-useful information. Library computers are different from laptops, which are different from the desktop at the office. Often, these are critically different in technical manners (work computers often do not allow installing plugins), but very often it's as simple as thinking about the degree of focus someone can pay to the task at hand. I've designed a fair number of desktop apps or websites for Customer Care representatives, or Telecom Managers, or others in specific work environments. Long before I thought about mobile context, I put a lot of thought into context of use in this regard. So, why do we spend so much time talking about context for mobile devices? Because they are even more portable than laptops, they can be carried to crazy places. But mostly because they are full of sensors. You can get a lot more information about individual use of a mobile than a desktop if you have access, and try. Trying is a problem. A lot of mobile sites and apps just do their desktop thing, but smaller. Even if you have made a great game or app or site and it's perfectly usable by tapping on a tiny screen, does it work for the context of use. Sure, sometimes I refer to context the traditional way: does it work in glare or darkness. But think about the Desktops (and if you haven't figured that out, laptops are the same) demand attention. If a common use of mobile handsets and tablets is "in front of the TV," then you probably don't want to be totally sucked into the mobile device. You might even need to be able to interact with others, and react at a reasonable speed to the conversation, or the action on the TV. Same for the dinner table, general chit-chat around the house, gardening, or anything else. When I say mobile must be designed with context in mind, I mean that it has to work with people's lives. In that same introduction section where I refer to context explicitly, I also say:

Lives take precedence Mobiles are contextual, here meaning they are used alongside people's actual lives. Desktops (and some and other devices) can suck people in so you can go ahead and issue alerts that blink in the corner of the screen, and they will be noticed. Mobiles are glanced at, used in gaps between conversation and driving and watching TV. They are even used to enhance these other experiences. So make sure they don't interrupt unless they have to. And if they have to, interrupt in a manner they will notice. A blinking LED, for example, is easily missed when a device is glanced at for a fraction of a second.

Sure, sure, you might still say I focused too much on distraction and driving. But have you see the task switching studies? Even when just on their mobile, users are interrupted by others, by new updates and by new thoughts of their own all the time (this link has some other great context of use numbers as well). Just because the user is not walking down the street or at dinner, doesn't mean they cannot be distracted. If you are not designing to account for distraction and social context, you are putting up do not enter signs for your users. All that said, context of use is only one facet of design. Check out my other seven Principles of Mobile Design. If you like them, or any of the other content up there you can pre-order the book Designing Mobile Interfaces from Amazon, for a pretty significant discount right now.

Salt mine recollections

In my old-timey RSS feed today was this article about going into the depths of a mine. Reminded me of my own trip to a mine. Sadly, long ago and there were secrets, so it wasn't a photo free-for-all anyway. But some recollections: By the time I graduated, I was already working as a graphic designer for my dad's little agency. One client was a large distributor of belts and hoses and bearings and so on. We made a promotional magazine for them, and distributed it a few times a year for a while. I was the art director, and got to lay out the whole thing, do press-checks, design stuff, and sometimes go tour the facilities. I missed the chicken plant, and Lake City my did went to, but I got to tag along to some of the cool factories. And, the salt mine in Hutchinson. I am disappointed to find that part of it is now a tourist attraction, but I visited when it was decidedly not, and I recall we went down to the bottom most level, so rather deeper than these guys. The surface looked like any factory, or warehouse really. Not a lot going on, and just big piles of stuff, and storage buildings. A few shops, and a rather small building that is the offices, locker rooms and led to the minehead. There wasn't much of a safety lecture, but we were required to wear a helmet, and keep a "self rescue unit" with us at all times. This was a little plastic box (on a belt) which apparently had a mask and CO scrubber, so we could stay alive a few days with minimal airflow. If you like to worry, then you'll love how they get you out in an accident. There are two large flat areas near the surface structures, one with a tractor shed next to it. The one area is a helipad, so they can land air ambulances. The other is for drilling to get you out. See, if there's a collapse, the elevator is apparently likely to go, so they need to drill you out. And to that end they have (are required to have, actually) a boring machine. Which is what's in the shed. How long does that take? Oh, a couple weeks probably. The elevator would be a nightmare for anyone not excited about crowded spaces, noise or feeling safe. Because it's an afterthought. The elevator is really this heavy bucket, and we ride on a little cage stuck to the bottom of it. When does it go up and down? When they have to haul a load of salt up, and pretty much no other time. That also means the cage is barely there, and there's fairly little underneath you. And nothing on the sides. Sure, railings, but no cage. You can stick your arm out and touch the walls. Which is the only time I got told to not do something. Went to touch the wall, while we were stopped (more to prove that it was open than to actually touch the wall) and was told that it's open, and we go real fast, and salt is abrasive, etc. so that's a good way to loose a hand. The mine itself was pretty uninteresting after that. More alien than overtly impressive. Dead quiet, even with machinery running not very far away. White! Huge. Mostly unoccupied so just dark caverns, but occasionally there would be a light at the end of a room and you'd figure out it's a vehicle, or a string of lights, at least hundreds of yards away. And they carved all this out. The archives were one of the more interesting stories. And, being not on our own we got to see them, more or less. Boring gray shelves in a room with a cage around it and a sign. They store all sorts of stuff, and notably the originals of all the Disney epics. See, there was film back then. Funnily, the only thing they will not accept for storage are film projectors. Really. Disney insisted on that, presumably because they don't trust anyone to not just thread up their movies. If I find photos of it, I'll try to post them also. But I am not sure where to find them fifteen years later.

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.

Fresh mobile design elements, just in time for Spring!

I almost can't believe it's been almost six months since my last update. I use this file almost every day. Which maybe is why I haven't gotten around to updating. I've been working a lot, working more (freelance in my "spare" time), writing a book for O'Reilly, and editing an entirely other book. When that comes out, I'll also be sharing the file I've used to make all those illustrations. But for now, I've got a few updates all throughout the old, well-used Mobile Design Elements document itself. As always, you can grab these from the same wiki where I'm writing the book, on the Drawing Tools & Templates page, where I also put up every other template, stencil and UI guideline document or link I can find. Remember, it's a wiki, so add your own if you find one. So, like I said, there are little changes all over. Mostly in the small components. But a few highlights: I've added an iPhone 4. Keeping to the resolution scaling didn't work for the doc size, so I had to make it different. Keep in mind. Just noticed I didn't get an annunicator row into the 4... Oh well. Sure, there are lots of places that have iOS device stencils, but if you like mine, now you have one. Compared to the smartphone fanbois, not everyone has this one. A featurephone. Specifically, a convertible one with 10-key one way, and a slide out keyboard. This is in outline mode only right now, but I will probably shade it someday, and will post that as well of course. Speaking of annunciators, I am trying to not just add items, but to organize them. So, all the system status items I could think of (actually, which resulted from research for the relevant section of the book) are now ordered like a typical annunciator row, and options have been added as I encounter them. Be sure to wander around and check out the rest. Pen input bits and pieces. More unscaled handsets for illustration. Lots of little icons and other pieces. A wholly new and fairly complete keyboard section, so you don't have to draw your own for quick comps. And more. Enjoy! Now, off to more writing and drawing.

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.

What the iPad is not quite doing (yet)

Every designer I work with seems to think that the iPad is ubiquitous. It's not. No one in my neighborhood has one. My doctor does, but they keep it at home, as the living room convenience device. Of course, something like half the people in the department I work in (as well as my previous co-workers, who I still keep in touch with) have an iPad, Galaxy Tab and/or eReader. Traveling through airports and spending time on planes, I see a lot more of them. And I've started seeing trends.
When the iPad was first rumored in it's final guise, there were numerous comparisons to the Star Trek PADD, or Alan Kay's Dynabook for the more learned and differently-nerdy. These comparisons seemed apt at the time, and I still see them. But watching the use of the various tablety devices, Media Tablets and especially the iPad is not a paper notepad replacement. And it's not apparently even about to be.
Earlier last week, I was in an all hands meeting. About 200 people (and seriously at least 50 have tablets of some sort). Those that were even brought, were in bags, or under chairs. They were with the laptops, as something unsuitable to be used in a meeting. And don't think this means that everyone was paying attention. Most people took notes. They just did it by pulling out a paper notebook or notepad, and writing with pen and paper. Over the rest of the week I kept my head up more, and looked for other behaviors. Indeed, tablets are used in spare moments alone, or in small rooms. They are used a bit as ambient devices, are used to consume content or look things up when the main computer is occupied. A few people here use them as their primary email computer when they come to visit our team room. But they are never kept out during a meeting when the laptops go away. I asked a few people why. Frankly, most of these people are /huge/ Apple fanbois. You can't ask them anything about the device and get a useful response. The first good one was from the person on our team with a Galaxy Tab. She was using it in the meeting... and she was just doing email. She said that typing with the virtual keyboard is too slow to take notes. I reluctantly got a few iPad owners to say the same thing. I had been pulled into that meeting with minimal warning, so didn't have my tablet, or even a notepad. So I took notes on my phone. The hardware keyboard was the killer app here; I have failed to use my previous mobile handset, with an on-screen-only keyboard to do this. But in other meetings I have used my clunky tablet PC to great effect. Handwriting recognition is approaching handwriting speeds, and if you don't live-convert, it's even faster. There's no page flipping, etc. and you just write and draw what you want.
Apple might agree with this assessment. Over the weekend, a patent was found for a stylus for iPads and presumably other capacitive devices they come out with. I think the implementation looks dumb, and maybe is just to get the patent fairy on their side; an inductive tablet pickup (from Wacom could be easily fit behind the screen, and add pressure sensitivity to boot. But I digress. Even Apple has, at least in the back of their head, a concern that the iPad can reach a broader customer base, and be a creation tool, not just the oft-argued consumption tool it seems to be, despite arguments to the contrary.
There also seems to be something about the size and glowing-ness of the iPad that discourages use as attention of the outside world goes up. A fun observation I've made is waiting to board the airplane. There are a lot of people for any single flight, and pretty much all of them have computers, and a lot have tablets. What I'm seeing is:

Condition	In use or in-hand
No employees at the gate	Headsets	Laptop	iPad	eReader	Mobile	-
Gate agent arrives	-	Laptop	iPad	eReader	Mobile	-
Gate agent announces boarding soon	-	-	iPad	eReader	Mobile	-
Previous flight is unloading	-	-	-	eReader	Mobile	-
Waiting for your zone	-	-	-	-	Mobile	Boarding pass
Waiting to get your boarding pass scanned	-	-	-	-	-	Boarding pass

No. No one uses paper books or magazines, except on the plane itself. Anyway, there seems to be a general worry that the iPad is too distracting, and too fragile. It gets put away not much after laptops. The relatively fewer Galaxy Tabs and Archos things I see are not much better. They last only another minute and a half. There also /seems/ to be something about the standby nature of eReaders. I never see the idle screens on those; they are pulled out of bags with a page displayed, the people read them, flip pages, continue reading and just shove them away. Not enough data here, but I suspect there's something to be learned with this as well.
So, lest you say I am just anti-Apple (and I do get accused of that when I ask these question), I am not really. I just don't think that any device is perfect, cannot be improved upon, and cannot be competed with. Were I hired to build a media tablet, or software for one, my competition would be Moleskine, and other trendy notebooks. Everything else is converging into mobile devices, one way or another, so I find it hard to believe that paper is not on our near horizon. The iPad, or Playbook or Xoom or anything else that's not just me-too can easily do a lot of this. I eagerly away the near future.

Viewed by lots of people at exactly the same time

“ ...with the rise of digital and catch-up television in the 2000s, the era of "linear viewing" was supposed to come to a definitive end. Just as we could create our own playlists on an iPod, we could now personalise an evening’s viewing...
Only it hasn’t happened. Saturday night event television like the X Factor and Strictly Come Dancing has revived the concept of live shows watched by whole families. True, the viewing figures are smaller than in the 1970s but in some ways the potential for collective involvement is greater because there are so many opportunities to comment and participate. Twitter, with its improvised invention of the hashtag to allow similar content to be searched and tracked, has allowed vast virtual communities to meet to discuss shows while they are being broadcast...
One of the defining qualities of TV remains that it can be viewed by lots of people at exactly the same time. ”

Author, columnist and cultural historian Joe Moran discussing the beloved, but somewhat exaggerated, history of the Christmas special. Right after reading a dozen glowing articles about how the iPad (et. al.) changes everything, I wonder how much the broadcast model really will change.

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.

Robovouchers That Get in Your Hair

“ This seems like a potential darkside in waiting. Aside from all the surveillance concerns you've suddenly got objects that can swarm in three dimensions and might get cheap enough for the economics of spam to apply. Never mind walking past a Starbucks gets you a coffee voucher on your phone - we'll just soak the area with robovouchers that'll get in your hair until you buy a cappucino. ”

The design and experience Russell Davies with some vague thoughts on designing behaviour and robospam, and the right-around-the-corner world of robot helpers, or annoyances, as he plays with a Roomba, a Sony Rolly and a good cheap RC helicopter.

Working Together for Mobile 2.0 (or 4.0)

Brian Fling's Mobile 2.0 thing is not quite a manifesto yet, and as he points out a lot in the document, has not even gotten the community traction that it needs, but is still something I mostly agree with. And, want to help with. I think things are mostly trending better. Worse a few places, but mostly better. I am thrilled with new things like Mozilla's Open Web App Ecosystem, so much so I talked about how much we needed one a week before it was shown off. Now, I'm gonna talk specifically to some of the points Brian makes in his document. And try to help with a couple of them.

A Mobile Web Coalition/Task Force: All my attempts to create a Mobile Web Coalition has failed since sending this email out. The problem is that no one has the time to invest in attacking such a hard problem. I’ve attempted to get corporate sponsors, but everything is just keen to do their own thing.

I have always agreed, and now that I'm applying for jobs, and am reviewing and trying to share what I made, I am annoyed how many are NDA restricted. It reminds me of Kim Lenox's post lamenting the good design of the iPhone because we all had many of these ideas already. And even aside from secret clients, I've worked for companies where you couldn't discuss anything. I once got smacked down for discussing on a UX forum information about the team that had been published in Business Week. This is all the antithesis of scientific exploration; we can't get far, much less consistent, without sharing, and collaborating. What am I doing to help? For several years now, I've been gathering up my mobile design elements (and other stuff, like touch guidelines, and type info) as a document, and sharing it with everyone as Mobile Design Elements. It includes a lot of components from deadly-secret projects, just pulled out of context and categorized so you can't figure out secret things. You can go get it from a page on my wiki there, where I share it alongside everyone else's stencils and templates. Use it as you see fit, share again, modify, etc.

Mobile Web Resource Site: Since the book came out last year it has sold pretty well, but I’ve still made no money from it, and all mobile inquiries that O’Reilly gets have been going to other authors. Looking back I would have been better off making all the text of the book free and public... but that is another story.

I agree we need one. I've been adding to a wiki of mobile resources for years under the Little Springs auspices. But no one else much did. And that is probably dead now anyway. What am I doing to help? I am one of those guys that O'Reilly is sending inquiries to. And (with Eric Berkman and some of our former interns) have been working on it pretty seriously for a month or so. It's just a patterns book, and it's general mobile, not just web, but I am trying to make it useful and well-researched. And most of all, part of our agreement with O'Reilly includes letting us put all the content on a wiki. So, I started a new one, and have added the whole outline, a dozen patterns (more every day) and a bunch of other resources: http://www.4ourth.com/wiki Please help. Or, don't contribute, but do feel free to use it so we at least all have the same language we work off. Since I am trying to write a book, and there's a deadline, try to be respectful of the info, and accept when we are jerks and cut off discussion in order to lock at least a version of a pattern, so we can move on. But do please help. I want this to be a community effort, so want to hear from you guys even if I disagree. And if you wondered about the name, it's mostly short and cool, but also because I think "2.0" is over used as hell. And if I think about it, I think we're in mobile 4.0. Explained slightly more at the home page for the whole site if you really care.

Mobile web zengarden:

I think even the desktop web is still missing the permanency and credibility of print design by having no big awards shows, or exhibit spaces. Mobile is far worse, due to the even speedier and broader variability of the devices. I am not sure the CSS ZenGarden approach is the way to go for this (and I'd like to see one less web-specific) but something is needed to let everyone see, to get good ideas (and preferably with implementation tricks shared also) and maybe a way to judge or rate for suitability, somehow.

Mobile 2.0 CSS Framework:

I know way too little about this one, so will leave it to others. I do worry a little about a major facet being so focused on the web. And not because I like apps. I like... everything. What about principles OS developers can follow? What about tools to encourage development of services, like SMS and location? Oh, and what about js libraries? And other plugin technologies, even for web alone?

I quoted Umair Haque in the final chapter of my book in his call for the Next Industrial Revolution and I’ll quote him again here...

There are days I almost hoping for someone to plot from their secret volcano base and take over the industry – even with something sorta crappy or restrictive – just so there's a single experience. Not just a single browser, but so interop becomes not an issue, and I can get location from the handset to the web, and... so forth. Way, way, way, too much stuff is locked out or restricted because of perceived quarterly returns, and I think everyone would be better off working together on standards. Clearly, none of us are CEOs and going to be able to go out on a limb (at least one strong enough the board won't fire us) and make this happen at any one company, much less across a whole chunk of the industry. So we need to start working, together, towards the goals Brian laid out. To work together, to gather ideas, to share them, to have goals as a community. And to talk about all these as a single community, so we speak the same language and start working together, instead of against each other.

Carnival #241

This week's Carnival of the Mobilists is hosted by mobile strategist and marketer Martin Wilson of indigo 102. I'm happy to be included again with all the other smart designers, developers and mobile thinkers. The Carnival is a weekly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, or anything else mobile, you should add this collection to your subscription list as well.

Context, or NOT…

Mobile context – As a road sign. Steven Hoober, Urges to think about users and think contextually. Mobile ‘Context’ is ever present in the ambitions of many when designing mobile applications, websites , interfaces and even phones. But somehow, it never gets really understood by many.

Next week the Carnival has no scheduled host. If you would like to host an upcoming Carnival of the Mobilists, drop Peggy Anne Salz a line.

ALREADY Seeing Significant Mobile Traffic

“ It used to be that us mobile folks like myself had to convince someone with a website to build a mobile version in the hope that they could then tempt some traffic their way. However, it’s a much easier discussion to have when the publisher is ALREADY seeing significant mobile traffic, and they just need to make the decision about how to serve it better. ”

The increasingly quotable Mike Rowehl in Thank You Twitter and Facebook, about how we've finally passed some tipping points in corporate mindshare; the chicken & egg proposition is over, and seeing traffic come from mobile (via, especially, twitter and facebook) makes them want to optimize mobile sites and build mobile apps.

Mobile Context - As a Road Sign

Okay, I think this went poorly. But I am too lazy to try again, and no one else wants to take the videos again either. Poor camerawork is from the 14 year old down the street, and I periodically look like I have Parkinson's or something, because... I have no idea why. A transcript, edited to make it a bit more sensible, is below the video, if you hate video (like I do) or just can't stand to watch any more after a while, but want to know where I am going with this. Context is something we talk about a lot when designing mobile applications, websites, interfaces, services and even phones. But somehow, it never gets really understood by a lot of people. They say "what do you mean by context?" And we end up explaining it to blank stares, and using lots of examples. I think this is because everyone is still used to the desktop. Context on the desktop computer means this window is on top, and this other one is sort of underneath that first one. But that's all it means. Because the rest of the time I am just sitting here, in a comfy chair, facing my computer. There's lighting, you are indoors, the screen is at eye level, arm's distance away, there's a full keyboard centered below it, and a pointing device off to the side.
A lot of people talk about mobile being "little glowing rectangles." But I think that frames the whole discussion wrong, because "little" isn't the key aspect of the device. And "rectangles" makes it too similar to the desktop, which is just a bunch of smallish rectangles (windows) inside a big one (the screen). What's different about mobile is the environment. I can be walking down the street, having dinner with friends, riding in a car. Or watching TV, and I keep wondering "who is that guy?" and instead of not knowing, or referring to a book, or going and getting on the computer, I can just pull out the mobile handset and look up this, or any other type of information, any time I want to. Mobile is contextual, in the sense that it works all the time, wherever you are, within your social environments, within the structure of the rest of your life.
The reason context is important is that it's what we live in all the time. Walking down the street, or driving to get a new license plate for your car. Putting aside your phone for a moment, you can understand context with analogies to other, actual interactions with the world. Like driving down the street, trying to understand traffic signs. Very near my house is a County building, where they do lots of stuff. Vote, get public health services, day care, crime lab, etc. And most people know it as the place where you go to get your new license plates, and pay the taxes for that each year. Most people who live in the area come here, but maybe once or twice a year. They come down the little street that passes by it, and as they approach it rings a bell. They can see the building, and they see a nice wide driveway to a parking lot. When they pull in, they see this: Actually, one on either side of the driveway. Off to the side is another that warns "Sheriff's Department Parking Only!" But how does anyone driving down the road know that. Because it was not placed usefully for the context of Driving Down the Road. The sign is aligned with the driveway, and is almost totally invisible (edge on) to people driving down the road.
If you aren't thinking about mobile design the same way, you are going to do the same thing. You are just putting up road signs in useless places also. It's easy to break up projects into pieces, and inherit process. It's easy to design for the way products are developed or built, or the way the old business process or legacy datastore gives the information to you. Or even just because you are designing it on a desktop computer, in that environment. And if you do this, you can easily forget about things like lighting conditions. Or the fact that minimum touch targets are only for sitting still, and people walking or in a bus have wobbling and vibration to fight with. You have consider the way people will actually use not just mobiles, but your mobile product specifically. Failing to do this will cause errors, frustration, and eventually people will stop using it. Sure, draw on the desktop, and use emulators and simulators to get the gist of things. But try your products out in real life. Bring paper mockups outside if you have to. Try competing products. But put them on phones and take them home, on the bus, and onto the street. Try them in the sun, in the dark before you go to bed. Take the bus or train for a change. Think about your users. Think contextually.