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.

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.

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.

Anchors & Curators

Curated content on the internet is all too much like the employee-picks shelf at the local bookstore (or video store). A selection, maybe even an interestingly thematic one, but just a collection of existing items. And presented with no other information to help you decide, but what you would find if simply searching on your own. Consider instead what people with Curator on their business card actually do. They collect, investigate, verify, and organize. They then build exhibits of some items from the collection, in a manner that tells a story. They add their own content. Maps, brochures, labels. Often, it all works together to make the point, to reveal deeper truths about the collection, and to encourage the viewer to explore further on their own. Compare these two paintings, though 20 years apart, the similarities help point out how the artist has grown in the intervening time. Or, consider the classic format of the national nightly news. Behind the scenes, the anchor is the Head of News. He sets the tone for the whole department, and makes key decisions about what and how it will be presented. Then as the on-air anchor he gives an intro to the story, frames not just the basic facts but the reason we care. If there's a graphic over his shoulder, it may well be a map, so you know where this is taking place. And then he hands off to a reporter who was on site, or at least pretends to be based on footage retrieved otherwise. And maybe, if it's a multi-faceted story, then you go to another reporter who gives another point of view; after the on-the-spot report, the reaction in Washington.
All this is all in relation to a number of posts* and discussions I've read and had with people about the point of online media. And it's coming up since I am being paid during the day to actually develop an IA for a very large product catalog, and integrate existing (magazine and other) content and personal details into one experience. I have seen at least a little of most of the available experiences. I don't subscribe to them because I am un-thrilled with the consumable media available. I still read paper magazines, because even cut down to save on costs, They do a much better job than pretty much any digital version. Web and tablet versions seem to have lost the key point of sidebars or related stories, and just use paper paradigms instead of developing their own; or learning from education, museum information design and broadcast radio/TV media even.
If this seems like a subtle change, it's not. Go back to the examples, and look at how much internet content is served. I call most of that a subset of "portal theory." An article is reduced to a smaller version, on a category page. It can be reduced to a smaller-yet version, even a title-only for a higher level category, for cross-linking or for the (portal) home page. Instead, I am starting to think that I want to break that whole model, and use the intelligence of humans, not just to tag and categorize and group things, but to differently re-order, to choose what is presented and not just sort, and to not just crop but actually rewrite content to present it most relevantly to the context. No, I don't have diagrams, or mockups for you. Yet. Maybe later. The only impediment, as I see it, is people. Good, smart, dedicated people who can write have to be found, persuaded and paid. And too much focus is on technology solutions, and paying for software. We have the software and interaction nailed enough. Now it's time to bring people back into the job of presenting information. Give me a news aggregator with the voice of an anchor, and I'll listen. But it could also be a great opportunity. To give a new type of voice -- or a reason to hope for the future -- to writers, and to the whole profession of journalism. If not this, then something like it simply must happen. Not to preserve a dying business, not just to make money in a new market, but to keep the public informed so we can all make decisions about the way we live.
* Now that I look for the links, way too many seem to be centered around Khoi Vinh. And he's a good voice in design and interactive publishing. But I swear others are talking about it also. And some rather interesting ones I can't quote.

** When searching for the links I ran across this, which I swear I didn't read before. It also has good points about curated computing. Very different ones, but the over use (or I say, mis-use) of the term "curated" is covered pretty well in there, if circuituously.

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.

Designing Requirements Documentation

About 14 months ago, [a large mobile operator] came to us with an interesting project for mobile handset UI. There was practically no mandate to design the interaction itself, in any way. Instead, we were asked to take a muddled mess of poorly-updated Word documents, a compliance spreadsheet branched from it a couple years before, and a pile of notes, and make... something, that would be a better specification for OEMs to implement the operator UI on their handsets.

All their handsets (first, featurephones, but various smartphones followed as secondary projects). It's not just paperwork, but a pretty big deal, and influences a lot of hardware, so many millions of users. And in that, it's actually a quite honorable design job. If there's a design, and it's good (or good enough) but is not being implemented correctly or consistently, then a key job for a UX person is to get it implemented, right, and well.

I for one take design seriously. Everything around the office, and even the office itself, are designed experiences. Poor proposals don't get us work, and poor specifications don't get our work implemented correctly. Designing documentation, even when just overhead, is ongoing and valid work I spend a lot of time on. See the mobile design elements, freely shared, for a hint how much we pay attention to this.

The openness of this specific request gave me great freedom to maneuver. We designed both a document and a whole new document format. And we took that "design" step pretty seriously. The first step was weeks of interviews. First with the operator – and with several teams from the operator. Then, with the OEMs. As an example, here are the people that we directly interviewed:

• Handset OEM product managers
• Handset OEM compliance managers
• Operator vendor managers
• Operator development managers
• Operator UXD interaction designers
• Operator UXD graphic designers
• Operator quality assurance staff

Remember, organizations are not monolithic, so teams from inside an organization may have totally different opinions or totally different ways of using a product. I knew this, which is why we set up so many interviews. And I was still surprised at how much variation we found, even with teams who work together every day.

For the OEMs, we sadly did not get access to all of them, nor to the document consumers directly. Like on a lot of B2B projects, there's politics and it can be hard to get to the right folks. But we got enough useful information by really prying and asking uncomfortable questions and absolutely promising not to share the direct answers with the operator. To encourage this sharing, there was no video record, just notes. And because of that, a backup note taker to make sure we got it all.

Then, we analyzed, and came up with some design principles. Which we had to combine with what the client team at the operator thought they wanted, and careful consideration of how each team perceived themselves. We didn't get far communicating changes to the overall process, strategy or organization. Though I got all excited about this, in retrospect that was dumb, or had to be approached very differently and more carefully.

So we dropped some of those issues (along with some great ideas for making it all a database) to focus on the print-style documentation and came up with these design objectives:

• Clarity – Remove ambiguity and the ability to interpret documentation in multiple ways.
• Consistency – Terminology and document style should be employed consistently for all requirements and documents.
• Extensibility – Use systems, such as permanent requirement numbering, that will not expire rapidly, and do not need to change as documents are added, removed, merged, or modified.
• Accuracy – Review for accuracy, but also design a process that encourages accurate documentation.
• Avoid duplication – Design a system of writing, organizing, and storing requirements that avoids or eliminates stating requirements in multiple locations, eliminating inconsistency due to out-of-synch updates.
• Reference – All references to other documents, other requirements and related tables, figures, or examples will be explicitly referenced in a consistent, repeatable, and discoverable manner.

Which is indeed derived from the research, but could also be guessed from heuristics if I had paid better attention to the many documents I have made, for many different types of implementation teams – although it was nice to have the proof in front of me when discussing with the client. A lot of the specification methodology was in fact already in my head from writing BRs, FRs, and deleveloping design documents over the years. And, as I have mentioned for some of these blog posts in the past, I just had to write it all down.

For example, every item is numbered. And the numbers are internally meaningless. We use a Google Spreadsheet which everyone on the Little Springs team has access to (this is not it, just a sample). You just increment that value in the shared spreadsheet by one, and type the number in the requirement spreadsheet. The outline-format (e.g. "Requirement 15.2.3.1") is fraught with peril, and violates a lot of permanence and repeatability needs. It took a while to get everyone on this, but it's fundamentally the right way to do it.

And once you have permanent, consistent numbers, you can do other useful things. Like have notes and figures that hang off the side. In the final spec they are tied with nice neat lines. But no matter what happens to format, you can't lose them because they carry that number. And... oh, dozens of other format and process tricks I won't burden you with. Here's what the final spec looked like:

This is a sanitized version with no references to the operator. The real one was delivered with their branding, because that's also a key to communications with the OEMs. It happens for a fair number of our clients. Again, the project is more important that we are.

We also spent a lot of time analyzing and re-writing the specs themselves. A totally consistent method of writing was developed. There's far too much to include here, but some samples from the "Guide for Writers of Requirements" (not distributed to the document consumers) include:

• Condition, Event, Result – Requirements should be written as full sentences, in the following format: Condition, Event, Result. Like this:
  From any text entry screen, pressing the [FUNCTION] key twice will "Lock" the key and afford the continuous entry of secondary keys (hereby referred to as "Function Lock").
  Here the condition is "from any text entry screen" the action is "pressing the key" and the result is all that about locking, and allowing continuous entry. Note that several preconditions, several actions, and/or several results may be expressed within a single requirement.
• Define, then Expand – Requirements are written in groups, where the title, any explanatory notes and (often) the first few requirements will define the group, or define the function or tool or set of behaviors the group is about. All the subsidiary requirements expand on this core definition with specific behaviors, processes, and display details.
• Free-Standing – Regardless of the grouping, each one should be free standing. The condition statement especially should set the full conditions. Never just say "on that screen..." or otherwise assume a context based on grouping with other requirements. Always give full names for each location, action, and item referenced.

And terms were standardized. "Handset" for example became the one and only term. Never "device," "phone" or anything else that strikes your fancy. Note the [Function] key reference in the sample above; square brackets mean a hardware button. These standardized terms and notations were then included in the introduction, with an explanation that the OEM implementation team could look up any term by simply searching for it.

We did a lot of card-sorting sorts of work. At once point we printed out each and every requirement. This was before we re-wrote them all and combined the dupes and errors, so we had around 9,000 little slips of paper. Which we stuck to walls in order to create categories and groups and sub-groups. Pretty much all categories from the previous document were discarded and rebuilt with this method. Which, in the interests of secrecy, we apparently did not photograph. Which makes me terribly sad now. It took up a pretty good percentage of the glass walls in the office at the time and was quite impressive.

And this covered the bulk of the work well. But even with re-structuring the document, it didn't hold together just perfectly. And, there were lots and lots of flow charts in the original operator documents. Like, almost 100 of them. Which really didn't do anything for me. No one else was bothered by it really, but like I said, we're designing a document and I didn't want the document to be just passable, workmanlike or good. As with anything I design, I wanted to take the opportunity to make something great. And here I sorta had the time to do so.

So, I began to focus on a systematic approach to diagramming with the hope of wrapping the flow charts back into the requirement text and making it all work together. I pulled a whiteboard over to my desk, scribbled boxes, and pondered things a lot. I also failed to take photos of this, so can only talk so much about the process.

Fundamentally, I realized that there wasn't that much going on in each section we'd created. I mean, the dialer shown in this sample (if you haven't noticed, click on the images to get a PDF of a few pages of this document) only consists of a dozen subsections, and a hundred and some odd requirements. If you go for that 2002 style of screenshots, depicting each and every state, it's dozens, or hundreds. Actually, I did some back-of-the-napkin math on this problem, and for some fairly small subset of information, it's actually like 200,000 variations.

No one is gonna draw that, much less maintain it. And no one can absorb this information and build a useful system from it. Which is a key issue with all specifications. Technical systems are so complex you can assume they are essentially infinitely, undefinably complex. So, you better come up with a better way. I solved this in two ways.

First, with modularity. I didn't explain them at the time, but in the gutter between the two columns in the spec page above, note those little drawings. They refer to these fundamental, reusable components that were pervasively applied. Many existed in principle, some we had to make up. And then we made all the drawings, in a specific style which you can find in the Mobile Design Elements document as "Mid-Level" diagrams. Because I couldn't come up with a better name.

These are shorthand for the basic module, which could be as simple as "a scrolling list" or even in-page widgets like a type of contact list entry. Any variations of the list fundamentals are covered in that spec point and don't need to be addressed when you talk about the address book. Most everything else is just data; the title of the page, what goes in each element. And soon you can define an entire chunk of the interface with a single drawing in a flow chart. (Oh, and note the little gray reference labels below the re-usable module above. Even that has components it refers to. Nest reusability for even greater efficiency of documentation and to encourage code reuse.)

So, I did. The flow chart above is as simplifed as it can be, but covers each and every path that can be taken. Really. And if you want more detail, that's what the bars at the top are for. They provide an easy way to find more information. Try it out. Look at that flow chart above. That very first box in the chart, "Dialer first entry" has a thick blue line which goes all the way up to a bar labeled "1280 Dialing a Voice Call." Scroll down in the document a few pages and you'll find a section (actually, a subsection) with the same title and number. And under that are a stack of requirements detailing how this function works.

Note that the 1280 bar links to the first three boxes. So, even though there are dozens of functions, they all collapse into these few states. The details are within these basic view states and don't need to be on the flow chart.

I did this exact thing for each section. Dozens of diagrams were reduced to about eight (I haven't counted lately, but it's not many) at the front of each major section, serving as a guide for those who like visuals, and as another way of viewing the data (a flow chart).

And, wrapping around to something I have always valued in my design documents, as a checkpoint that the design works. I think documentation should not just communicate the idea, but help the designer, whether it be UX or software or systems or database design. Making up these flow charts exposed a number of issues; impossible conditions or endless loops or undefined states. All of which we filled in.

And since it's all designed to be easy to understand (the client has essentially a more explicit version of this essay), anyone revising it in the future can use this, even if they don't know that's the intent. When they add a feature, they hopefully go back and add it to the flow chart and if it doesn't fit in there... well they ought to notice that and work it all out. A self-correcting system.

I can't ask a lot more of any of my work than that it do good, help someone, and last for a reasonable amount of time.

In case you want even more about this, there's a follow-on about working with requirements documentation and I am now presenting a session on basically this topic at the Design for Mobile 2010 conference>. Even if you don't want to see me, 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.

My Mobile Mantra: People First

Mobile is not iPhone or iPad or N8. It's not Bada or Symbian or WebOS. Mobile is not Opera Mini, or Skyfire or Netfront. Mobile is not sliders or clamshells, QWERTY or 12-key. Mobile is not touch, or multi-touch. Mobile is not Foursquare, or Facebook, or MySpace. Mobile is not Twitter. Mobile is not MMS, or BBM, or SMS. Mobile is not resolution or GPS, or front-facing-cameras. Mobile is not CDMA or GMRS, WiMax or LTE.

Mobile is not successful due to amazing marketing, or great pricing, or because it's fashionable. It's not even successful because it offers new capabilities to everyone, although it also does that.

Mobile is an unspeakable success because it lets people be people. As obvious as it seems, we're no longer tethered to wireline phones, or movie theaters and TVs, or pinball arcades, or typewriters, photocopiers and desktop computers.

Mobile works because it lets people work the way they want to, and the way they always have. Mobile lets people be mobile, and read what they want, and watch what they want, and take photos of their vacation, and share their thoughts with their friends, their family or no one in particular.

Designing for mobile – and I say now designing for anything – is an exercise in designing for people. Sure, it's always been a great idea to consider users; but not just how they interact with a machine, or a website. If you step back and look at the way people really work, and want to work (or play, or share, or create...) then you are on the right track.

Whether the product that comes out of this is (or works on) a large chunk of iron, a wheeled vehicle, a desktop computer, a website or a mobile handset – or many of the above all at once, is of no particular significance. When you consider people, and their context, and address it right, that is what I consider designing with a mobile mindset.

Certainly do not get locked in and decide before anything else to design a desktop website, but also don't design for mobile first. Design for people first.

I think this will be my position at 5pm on 21 September when I talk about "Why and when to design for mobile first" with Scott Jenson, Barbara Ballard, Luke Wroblewski, and Alan Tifford at Design for Mobile 2010. Come see us and join in.

Why should I be the expert?

Tax prep software, I am told by folks who build it, is an expert system. It knows all about it's domain area, and solves problems for me based on this knowledge, and likely information and outcomes. So why am I the expert? I regularly have no idea, at all, what it's asking me but the assumption seems to be that I understand the jargon perfectly. As 2008 tax paperwork begins trickling in, I start thinking of the great idea I came up with last year. How about I don't fill out forms the way the government, or any tax-expert does, and instead I just gather my documents, and enter those. So, right now, I can go to the TaxCut site and say I got a form. They guide me through obvious choices, and I pick "its from a bank or investment management company" (of course, they offer last year's forms and companies as an option) and tell me it's probably a 1099-INT, then I enter that info. Weeks later, as it determines I have probably got everything entered, it asks to make sure, and then goes through all the questions about if I have any farm income, or am blind, or dead or whatever. But why not look at the actual use case, of everyday folks, frustrated by taxes and the piles of paperwork, and use that to solve problems instead of creating more.

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?

"Lo"? What the !@#$ does that mean?!"

One of those standard things I think all homes should have is a smart thermostat. We bought this one shortly after moving in. Though I agonized trying to find a reasonably easy-to-use one that fit the space, I failed. Its sort of junky. Do not buy it.

One thing is that its sort of hard to manually control. There is no real "fan-only" setting, for example. You end up working around the software a lot, to trick it into things.

Lately, its been worse. Its performing uncommanded actions. You set it to manual, click over to the air conditioner (which is still "unplugged" so will not engage) and if you wait a bit you can see it go "nope, you need heat." The little heat-mode icon lights up, and then the wavy lines that mean its making heat light up. Go to the basement, and yup, the heater is on. On a 76° day. One other hint, the temp display has a tendency to say "LO" instead of a number.

So, I finally give up with shorting leads and beating it with a screwdriver, and call the tech support line. Turns out LO means off scale low. The tiny, stupid computer in the thermostat thinks that its freezing cold. But its not, its just a bad temp sensor. Apparently, it feeds signal directly as a resistive signal, and 0° is about 0 volts.

Okay, its not the computer's fault. Its the designers. While its nice it says (cryptically) off-scale low, instead of a falsely low temperature when it gets a zero voltage response, who decided that the thermostat is smarter than the user? I am requesting "cooling" mode, so why switch to heat mode all by itself? Or, how about a spurious data sensor? It seems to disregard the 95% of the time it gets valid temperatures in order to fire some emergency recovery mode if it gets ANY zero-voltage temp gauge readings. This is poor design, making me sweat and wield a screwdriver needlessly.

More on trustworthy data

You are flying a high tech airliner, at night, over the ocean. Your instruments become useless, airspeed and altitude randomly moving from off-scale-low to other, arbitrary values. Or are they true values? The computerized control system reacts to those with a series of warnings, some of which are contradictory: over-speed and stall, at the same time. Without any visual frame of reference, there's no way to tell even roughly how high or fast you are going. What do you do?

Ask for help.

Air traffic control has radars covering the area (it does for most places airliners fly, but not some of the deep ocean routes) so you call back and ask them to give you accurate information off their screens.

They can easily, if slowly and by voice, give bearing, direction of travel and speed.

Who knows what is wrong with this last data point?

Altitude is not derived from radar data, but is instead telemetry; the aircraft sends the information, along with those identifying codes at the top, to the radar as part of the transponder data. If flight instruments are inaccurate, its very likely -- and in this case, indeed true -- that the number on the ATC display screen is wrong also.

And as a result, you fly into the ocean.

Aeroperu 603 New York Times article Wikipedia article

There's plenty more to hate about this crash (and the similar Birginair one) from a human factors point of view, from providing static and pitot port blocking devices, to the difficulty the flight crew has of focusing on a problem with so many conflicting instruments and warnings.

But I think there's something to be said for the problem of displaying the trustworthiness of data in this one narrow context. ATC systems have worked like this forever, and will probably continue to do so. I was surprised no one seemed to be aware of their manner of operation. And remember, the ground controller does not have as many issues as the aircrew, so should have had a chance to think over the issue. I presume he was, deep down, aware of how the system works.

But I generally avoid anything that has training as its backbone. Would there be a way to denote how information works, or where it comes from? I have nothing now, but its worth considering. The big problem as I see it is that the information is of mixed sources, and therefore mixed reliability. When transponders fail, or are turned off (terrorists, smugglers), the data supplied by it simply disappears. But before that, its displayed in the exact same manner as the systematically, radar-derived data.

Note that just because air travel is a high-reliability system with lots of history, these systems are not bulletproof. Changes to the displays frequently are poorly implemented and cause confusion. I suspect much of the design is status quo, and is not that good were testing to be done on it. Problems are alleviated with training and procedure, leading to accidents that result from poor training, breakdowns in procedure, and poor communications of changes in either.

Rounded-bottom Design

Much of what comes out of slanty design, and possibly the whole manner of designing architectures of control today, bugs the hell out of me. Its been bothering me since I read a spate of related articles a few months ago. I like the concept at its core. Don't prohibit by labelling, but make it impossible for users to do the wrong thing. Much of the slanted design stuff seems to split the difference, and feels user punishing still. Sloped floors leading to baggage carousels (scroll down in the first link to slanty design, or try the ACM article, if you have a membership)? Toronto for ones has snaking baggage rooms that already solve this dilemma. I am sure others have solved it in similar ways. Though the bags do come out one place, its inconvenient to get to, no one notices it, and there are other things to distract you around the room, like TVs. So people spread out, and no one fights for space. And, when full of people, sight lines are poor, so you just see your little lane, and don't race to the end of the room to get your luggage as soon as it comes out. I've been trying to keep track of other bits of good design that avoids problems without punishment. And then I saw the fire buckets on a UK TV show. They have round bottoms! And they are still made, though this one is rather less aggressively curved. Seem to be for factories and ships, more than places like police stations these days: In case it doesn't make sense, normal folks don't have hooks all over the place. Buckets get put down on the ground in normal use. A round bottom prevents use of the bucket as a normal bucket, so they won't get messed with or stolen. Brilliant. And a machine-age solution. This one, with a wire to serve the same purpose is from the turn of the last century: Personally, I prefer the very obvious ones, as then it doesn't just not work to stand up, it so clearly doesn't work for any but the designated purpose that no one would try it.

Terrible Interface of the Week: Redbox

The wife, a friend and I are hanging out at our house this evening, and after watching all the Dirty Jobs on the PVR, and everyone else decided that they hated the Netflix I have, and didn't want to watch my Thai homage to 50s Technicolor. Plus, we needed ice cream. So, off to the Hy-Vee. And the video department is being cleared out. Now there's a Redbox off to the side: Besides being the only rental solution at the store, its something I had never actually used before so I couldn't resist. Home deck is not bad. Big, obvious choices with no gimmickry. So I click the obvious one, the "Rent a DVD" option. The expected screen comes up, with a list of movies... ...and that's it. There's no overall count of movies available, location in the list, search box... wait. There's no search box? Really, they seem to think that the limited selection (I didn't count, but like 50 movies) means they think browsing is enough. But its really no good. And the buttons are so generic, like any bad PINpad. It took me a good 15 seconds to figure out there was a 'next' button. If it was on the side, or had a big arrow maybe it would work. There is a minor ability to sort, but its not that great. There are two small tabs at the top to sort by release date or title (I guess, alpha, the default). They are small, the color highlight is vague (I got it, but a friend read it backwards) and they are hard to hit. You can get above it, so the cursor appears to be on it, but its not activated; that's a serious failure of basic design principles. The tabs are hard to hit at that target size due to the bezel getting in the way and casting a shadow, and the parallax error. Touch alignment isn't perfect. The scrollbar (used a few other places) is just as bad in the same ways. Perhaps my favorite is when you press the "Online Rental Pickup" option: There are clear, animated instructions. Unless you don't want that option. At which point you have to wait for timeout. There is NO back button of any sort. Nothing to get you anywhere else, to a help screen or anything that is available in the rest of the application. You'll note I don't comment on the payment, delivery and return processes. That's because we didn't rent anything. As I said, we were somewhat in the mood to get something to watch, but the inability to actually find anything but top-40 playlist items from the Redbox meant we didn't begin to consider getting anything from there. We actually spent time looking thru the clearance bin (from closing out the store video department) instead. Even not finding something worth buying, that was a more satisfying browsing experience. Aside from the selection, there may be something satisfyingly social about browsing movies on a scale larger than touchscreen. Have to think about that some more.

Why do we have to wait for receipts?

Leaving the house this morning, I notice the car is almost out of gas. Not "glowing light" bad, but Lawrence is a long ways off, so we aren't gonna make it. So, I stop at Quik Trip. And when I am done and the hose is hung up, and the fuel port is all sealed, I am still waiting for the receipt to print... Though I have done this thousands of times, I just realized, this is a friction point. If I had the choice, I wouldn't put up with a wait in the cold here. I feel this is yet another case of modern technology being implemented in a way reminiscent of the past, yet missing enough of the point that it makes everything harder. Think of a receipt in a simple (or old-time) cash register, or adding machine. Its a record of what you /just/ typed. A couple lines get printed automatically when you press the button to say the transaction or calculation is complete. Then about 1 second later, you can rip it off and look at it. Why don't receipts on computerized registering systems (at the grocery store, at the gas pump) work like this? A transaction starts: print the header, date time. Pick a product, print it on the receipt. Total it, and it prints a couple lines. Etc. By the time you get to the end, Of course, in many stores, its even worse: You have to wait for the itemized receipt, then wait for the credit card receipt the store keeps, THEN they print the receipt you sign. And you sign it while the system and cashier is idle. Great planning. So, I have no faith anyone is actually working on improving this. Get used to the wait.

Warning! Cool new feature!

Despite their best attempts to hide this sign on the filthy wall behind the ATM (is that a spider above it?), I noticed this the other day at the local Hy-Vee. Its pretty lame, but I unfortunately know what they are talking about. The Sprint campus had one of these, and its communicated even more poorly. Check it out: Danger, envelopes are prohibited. You jerk. Now, I know what they mean and why they are doing it. There's a not very new law that everyone is finally complying with to save money. Your checks are basically destroyed at the receiving bank; a scan (and a file of meta-data) flow electronically across the countryside to move the funds about appropriately. Scanning at the ATM probably means they can skip several steps, and just toss your paper check in the shredder. You do the scanning work for them, instead of the box of checks and envelopes going to a fulfillment center where they are opened, scanned and so on. Speeds payment also, which is always supposed to be good. Though I always like the delay in fund removal that giving someone a check affords me. In practice, to the end user, this is pretty cool, and you get to see your check on the screen before confirming everything, so its pretty clear the system worked correctly. But, as you can tell, I have problems with the way at least Commerce did this. I suspect most other banks did just as poorly, assisted with obtuse ATM designers.

1. As you can see above, the communications is awful. Take a feature, and turn it into a constraint. It practically reverses the standard joke to "its not a feature, its a bug." I am not a communications designer, but I am sure there's a way to communicate this technical requirement, without it being a prohibition on user behavior. Sure, it says please, but aside from the warning-like graphic, there's not a positive word on there; nothing about the new feature and just insert the checks alone. Its not even that close to the slot. Anyway, there are no envelopes, and I don't think they would even fit in the slot, so its not a huge risk.
2. Speaking of no envelopes, why not? No, I know its supposed to scan the check, but placing deposits in an envelope has been going on for...ever. Before ATMs, you were given little envelopes (or similar devices) for cash or check deposits thru the pneumatic tubes or power drawers at bank drive thrus. Almost anyone who has banked at all will be used to this system. So, why not a transition period? Provide envelopes, but encourage users to try the new envelopeless service. You have a full-color interactive system, so nifty interstitials or banners (better) can be loaded into the process. After 6 months, remove the envelope rack, and after a year remove the capability of accepting them at all.
3. And this envelope habituation brings up another real-world issue I, for one have. I never endorse checks going into ATMs. Its not required by law (I am very sure) and doesn't seem to be an issue in ATMs (never had one rejected). Also, I forget. I don't carefully prepare for my trek to the ATM, and they NEVER have pens on site. So, by the time I am there, its impossible to sign them. No, I am not a girl, so I don't have a purse with pens. Okay, see any pens on that Sprint location ATM? Neither do I. Yet, they seem to be scanning for endorsement, and get mad if its not present. This is just poor design. Provide a pen, or two for when it gets stolen. Provide a bucket of them like envelopes, and don't worry about the loss rate as its free advertising. Or, don't require it, and if some new anti-terror legislation does indeed require it, provide a way to authenticate in some other manner.

Selectors & Labels

Disregarding handwriting, counting on your fingers and even typewriters as being just methods of indicating, the first method of selecting information for use or further processing is the abacus. This is a direct selection method. The selector and the indicator are joined, or in this case, the actual same object (the bead). The slide rule, to include various manual rotary computers, are of course very similar. There is no further removal of the user from the interaction than by moving the relationship bars or grabbing the edge of the indicator slider. The magnetic compass similarly has a manual dial which allows establishing relationships of position and azimuth, and when coupled with constantly updating magnetic information allows monitoring of bearing and heading during travel. Such interactivity continued thru to relatively technical, computerized systems such as the 1960s-era flight simulator control panel shown here. The radio frequency selector (a similar method was used on aircraft of the era) is a single dial for megacycles (the 100s, 10s and 1s place from a limited list) and a dial below it for the tenths place. An arguably similar method is most early adding machines (and some early cash registers). In the pre 10-key days the were of the direct-entry type. A typical layout is an entire row of all 10 possible digits for each place in the total number. Selecting a value per place leaves the key depressed, serving as an indicator. Eventually, registers (lists of the numbers selected) started appearing. This led to the 10-key pad allowing an indicator separate from a selector. The adding machine evolved into the current form with a single set of entry buttons, and a register of entered values (or a printer). Really all 10-key devices (even aviation radios these days) use this model. The desktop computer is more or less the ultimate extension of this, with the keyboard and mouse often not even attached to the display device. And now, for some time really, there seems to be a push to move back to directly connecting the input and display, or action. One good example is that bastion of selectors and indicators, the light-up elevator button for each floor. Which is being reconsidered as a 10-key system, with its predictably unpredictable results. Touch screens are the most obvious and dynamic of these though, from Cintiq-like products, to of course mobile devices. I have seen two things that bug me about touch screens. One is that the electronic tying of the functions is rather tenuous; display-thickness induced parallax and processing delays means the pointer is near where you are indicating, not at the tip of the stylus (or finger). The other problem is the tendency of practically everyone to forget their history, so any good designs (or bad) from the past will not be applied. As I've touched on before, the iPhone has this issue in several regards. See a video of how the user's finger (okay, its me) covers the indicator/selector, so you have to try, then move out of the way to make sure it worked, or fix it. For all my whining, a solution might emerge over time. Eventually some good design standards will be developed for these products, mergers and product failures will cause consolidation and with any luck the good ideas will rise to the top, relatively universally.

Think Design - Live Design

The Adaptive Path folks are in the process of interviewing everyone who is presenting at UX week this year. Good stuff in general, but today it was Bill DeRouchey of Ziba Design and the History of the Button blog. Lots of good stuff, but he made one great point that is so obvious to me I never really formalized it, much less said it:

Interaction designers, of course, should be trying to deconstruct everything around them to better train themselves as interaction designers. And the fun thing about that is we’re completely surrounded by examples, it’s all the devices in our daily lives. It’s the cell phones, microwaves, ATM machines, computers, printers, and so on. We’re surrounded by buttons and icons and little blinky lights that can give us examples of how people think about devices and interaction design because there’s one thing that’s definitely true, people don’t approach the product from a void.

Since I am not sure everyone else does this, here's just six things I have done recently that inform my understanding of our world as an environment someone designed:

• Note everything bad about the ATM interface. Is there any reason its bad? Are there any security flaws? Is a warning sticker the best way to inform users of a feature (envelopeless deposits)?
• Compare and contrast pinpads. You know, the payment interfaces at stores. Why does the hardware store have one, but you cannot swipe? Why does Target think its a good idea to suck you card in? Why do almost none of the softkey devices use them, and none use them consistently? Why are they all so different?
• Replace the mirror on my car, with a similar but not identical one from a junk yard. Figure out how the relevant pieces come apart. Figure out how to modify it without destroying the base object to fit the new part. Think about how the design is optimized for ease of factory assembly. Note the construction, materials, structure, wiring and assembly method and try to determine how much this influenced the layout of buttons and lights. Does there seem to be anything sub-optimal in the control placement that seems to arise from these considerations?
• Build a birdhouse from materials on hand. Find the specifications (hole size, position, interior dimensions) for the type of bird. Consider environmental issues (outdoor use will be hard on the materials and construction). Make provisions for repair, ventilation, mounting.
• Compare the manner in which the quick-start options work on the two microwaves at work, vs. the one I have at home. Why are they different? Which is better to me? Is it a result of habituation or is it truly easier to use?
• Look at the way barricades and signage are placed for a construction zone. Is there a better way to route traffic? Is there a better way to label the change? Is it more confusing at night, or less?

What have you observed lately?