Recent Blog Posts

AdWeek just posted this interesting article on companies creating interactive experiences for moviegoers. I think this is a set of great examples of breaking down the barrier between physical and virtual worlds. As always, the mobile is involved because it is the device actually in everybody’s pockets.

Briefly, the article talks about a couple of companies making interactive software (and I think hardware in one case) to be installed at movie theaters. Audiences can participate in crowd games, can vote on surveys, and so on. Results are displayed on the big screen.

Of course every game is sponsored (this is AdWeek, after all) and the advertisers are improving brand recall. But it’s also a win for the theaters, the filmmakers, and the audience.

I believe that a major area of growth for retail stores and other spaces is creating extra levels of customer engagement via digital services, accessed by the mobile. Examples can include

• interactive store directories, so you can figure out whether they have what you are looking for


• projects for home improvement stores or recipes for grocery stores, letting you figure out what could be done with the Sputnik-looking vegetable in front of you, and where to find all of that stuff in the store


• user and critic reviews, similar items, back ordering, and more at book and music stores


• increasing interactivity and audience engagement at theaters


• storing my preference for large mocha at my coffee shop, and letting me buy it without standing in line


• airport information interaction – when is my flight boarding, can I change seats, where was my luggage the last time it was scanned, etc.


• information, beer ordering, statistics, small-screen replays, photos to save as memories at sporting events

There are more ideas, but this is a start. Each is, essentially, the sort of interactivity you might put on a well-designed web site selling the same services, except accessible in the physical environment.

Oh, and don’t forget that every one of these has a location component. And many have a phone-as-wallet component.

I think interface design, the design of visible items on a page or screen, is pretty well understood. Whether you learn it viscerally through art school, by repetition through design school, or by rote through some digital design program, the basics have been well understood for some centuries, and apply perfectly well to print, broadcast or interactive designs.

Interaction design is still being developed. Sure, some basic underpinnings go back to maybe the 1920s, but designing open-ended systems like we mostly work on anymore (web and application design) is still evolving. There are not even universally-accepted job titles and document descriptions.

I can, without stretching at all, say that I have been designing interactive systems for 15 years. By no means were the first years all good – or even highly-conceived but misguided – but for probably the past 6-7 I have come to certain understandings which have begun to prove themselves enough they are beginning to become Laws of Interaction Design. At least for me.

Artifacts and documents

Out of design work (and from now on, design means interaction design) are produced a number of documents. In some contexts I will call these "artifacts," which is a wonderful name for the superset of every sort of file that is saved for a project.

But increasingly I have become certain that design produces documents, and a key test of whether something is a "document" is that it can be printed. It doesn't actually have to be printed, but that fact that it can, and that it preserves the essence of it's communicative ability when printed on paper, makes it a document worthy of carrying design.

There is probably a little of my love of paper in there, but really it's all pragmatic. I have worked with plenty of teams on site, or with clever electronic distribution systems. And with too many remote teams I never see. And either way, amazing amounts of paper seem to get created. All too often, outside of your control. Beautiful animated renderings are printed on old, letter-sized black & white lasers, marked up, and faxed around. Yes, faxes are still in common use by your client.

And this works well for people. Even the Nintendo DS generation is comfortable writing on paper, shuffling, comparing, attaching Post Its®. You are, all in all, better off internalizing this, and designing for paper consumption.

And, yes, there is prototyping

In much the way no one seems to know what a persona is anymore, prototyping is being turned into a monster, that seeks to do far more than it really should.

Prototypes are functional models. They may not be very functional, and almost always should not be. Stub data, single happy-path flows, comped graphics. But they are functional in some way. To build a functional anything, you need a design. Quick, try firing up the lathe and making something out of metal. There is design before prototyping, always.

So admit it, and use prototypes for their proper use. Explore design ideas, test them out on users. Run them by marketing and brand. But please do not give them to developers and expect anything like it to come out the other end.

Drawing Interaction

I strongly feel that design is tightly coupled to actually putting ideas on paper. For GUI of any sort you need to draw to execute the design, as well as to communicate to the consumers.

So, my design tips for interaction drawing are very closely related to mindset issues. Keep these in mind during design, and be sure to depict them when drawing. If the two activities are one and the same, all the better.

1. You must think...in states — Forget the site or app, forget the screen. For interactive systems, especially as refreshless-dynamicism increases, the state is most important. If something changes – due to context or user input – the screen is going to change, and you need to depict that. It's easy to go overboard; don't worry about transitions, for example, just limit yourself to states where the user is most likely to interact with the application.
2. Show your moves — Arrows are your friends. If a link goes somewhere, add an arrow, and send it over to that state or screen. If it's too far away, just label the end point in your naming scheme. However you do it, everything needs to link up. The business owner, developer or tester should be able to run their finger or hiliter along your diagram and follow every path, link, action and interation.
3. Call a button a button — This is a task done at the wireframe level. Wireframes vary a lot in fidelity; simply the fact that we're showing this much interaction makes them a lot too detailed for many folks. But the key is that they are not final design. Use this to your advantage. Don't be coy about what is a link, or a button or a pulldown. Make sure everyone knows they are links, buttons and pulldowns. Use the common, learned vocabulary of such interaction items, such as my mobile design elements to make clear, even cartoon-like representations of everything on the page.
4. Show it all off — If it's under your control, and the user interacts with it, show it. For mobiles, there better be a softkey menu attached to each screen. If there is time before transitioning, show it graphically on the flow arrow. Make sure everything is there, on that page, and is at least recognizable without too much reading.
5. No one reads anymore — I can count on one hand the number of testers who have come back asking for clarification on the wording of a detailed design document. And only once did a developer ever ask the same. These are complex systems, so you will make errors; the fact no one asks about them means no one is reading it. If they are not reading it, they are not designing and developing the technical systems correctly. Make your drawing talk for you. It's an interactive, graphical interface system, so you ought to be able to depict it graphically. Notes are fine, but it should be clear from graphic representations generally what the note will say, and that there is a note to be read for clarity.

Artifact errors

I'd love to be able to chat about all of this in a manner intended to get pure and perfect design. But I want to emphasize again it's all practical, and intended to get your design produced.

A recent product I designed had a key feature that was so simple it was not immediately clear. The primary path to perform the action was automatic; the user did it without even really explicitly trying. There was a sort of backup path, that was somewhat convoluted and difficult, to address some special cases. But the way I depicted it, this difficult path is the only one really visible on the design document. It took a long time to make the product owner happy again. Eventually he was very happy, but this looked like a huge error on my part.

I tend to call these "artifact errors." It wasn't really an error, but appeared to be so due to documentation. In this case, it "just" annoyed the client. What if it slipped by them, and was instead not well understood by the developers, so this key feature was essentially left out?

I learned my lesson, again, and have tweaked my document creation process to try to depict such non-interaction interactivity more clearly. I hope. It's a constant learning process, and every time I think I know enough to sit down and write a book, some project comes by and throws a wrench into the works again.

This week, we're finalizing the Design For Mobile conference agenda, and celebrating by chatting with the notorious Luca Passani of AdMob. Among other things, Luca is the chief personality behind WURFL and WALL. Not only will Luca talk about designing with WALL Next Generation at the conference, but Brian Fling will provide a pre-conference workshop on mobile web design.

Barbara Ballard: What excites you about mobile?

Luca Passani: The challenge. Mobile phones are extremely poor internet clients. People don't buy phones to go on the Internet. They buy them to make phone calls. Almost every mobile device comes with a mini-browser these days, but the user experience is so poor that people continue to buy newspapers to look up the day's events, ask passers-by for directions, and or to call a phone number to reserve movie tickets. When people perform the functions above and others like them using a mobile application I have designed and built, I get a little satisfaction.

BB: Tell me about your history in systems to enhance mobile usability, including Openwave.

LP: When I started working with WAP in 1999, it was clear to me that development for mobile devices needed to include usability thinking from the ground up. This did not go unnoticed to Openwave (or Phone.com as it was called at the time). That was the beginning of a journey in which Openwave was asking me to evangelize about WAP usability to developers all over the world.

My views about usability have always been sort of extreme. I always believed that the success of a mobile web application depends on letting the UI design go very deep and influence the business logic. This is quite a strong statement, particularly if you consider that pretty much all of the web development frameworks built over the past 10 years were built on the assumption that you have data, you have business logic, and then you have the view part which can be adjusted to present any business logic. My approach has always been different, in that, the system should be defined by user experience. If business logic must be modified to accommodate user experience, then so be it.

BB: What are the origins of WALL? How will it progress?

LP: There was a point when Openwave was asking my department, Developer Marketing, to promote the creation of XHTML-MP sites. WML devices were dominant at the time and developers could not see a clear advantage in migrating to XHTML. One problem was that XHTML had dropped a lot of the good ideas of WML (soft keys, keyboard accelerators,... but I digress).

The solution was to create WALL, a tag library that allowed developers to create mobile sites for all devices with one markup. I did not have programming resources at the time, so I ended up writing it all by myself. I would do a lot of things differently today, but this did not prevent WALL from being a huge success. WALL was launched in 2004. It was a great resource at the time. Today's devices and mini-browsers are more advanced than what was available in 2004. For this reason, sites built with WALL look a bit 2004-ish today. This problem will be solved by WNG (WALL Next Generation). WNG is a complete rewrite and redesign of WALL, allowing developers to fully utilize CSS, yet still gracefully degrading on older XHTML devices and WML. [ed: learn more at the conference!]

BB: What can you tell non-coding designers about device diversity?

LP: Every device is different. Full stop. Seems easy enough, yet people continue to complain about standards and lack of standards and bad support for standards. Well, this is the way it is. If you don't like it, keep doing web development.

BB: What is the biggest obstacle to getting good design into the marketplace and your designs implemented?

LP: Device diversity. Network operators. Content transcoders.

BB: Considering anyone planning on coming to see you speak at D4M, what book / article / movie / blog would you suggest they read to understand the way you think?

LP: GAP is a good introduction. It puts web developers on the right track of thinking mobile, raising awareness and challenging everything they think they know. Once they have absorbed GAP, then they will understand why WURFL and WALL exist, and why they may want to adopt it for their projects.

Check back periodically for the rest of our interview series with the speakers of Design for Mobile 2008.

The latest release of google maps added in location for all of us with GPS-free devices. This works just fine for me, as I know how to navigate so don’t go much for routing software anyway. I often pull out the maps when I am somewhere different from last time, so if I want to drive somewhere, now it gets me to the ballpark, at least. And for my other use case – search an area for restaurants, or tires or stencil ink – it’s perfect.

Except when it’s not. Saturday my wife and I took some bunnies orphaned from someone else’s lawnmower accident out to the woods to be released. They did fine. But getting there was too difficult. I popped open the map to remind myself how to get there. G-maps had an issue getting location, probably because we were down in the low-lands along the river, but I was fine and just used it like always, as a scrolling map. Found the location, then the app decided it knows where I am… and moves me over there.

Yeah, it was inaccurate by several miles. But regardless, I had manually scrolled and zoomed to someplace, and therefore I probably care about it. What possessed Google to disregard user input, and scroll me over to where they think I should be looking?

Similar things happen all too often on mobiles. While typing a text message, a full-screen alert interrupts you to say a new message has arrived, maybe destroying the current composition. It’s almost impossible to type web addresses on most phones, because the useful symbols are hidden away. It takes six keypresses to find out what call you just missed because you couldn’t get to the phone on time. It’s easier to accidentally completely delete a new MMS than to send it.

Not all of these happen to everyone, every day, but they are typical issues. These are the sorts of things I have to listen to when I tell people I am a mobile designer. And they are not just bad in some vague way because they annoy users, but because the device is ignoring context.

Yes, context again. Any time now, as we keep saying, context awareness is going to cause all sorts of neat things to be possible, but there is already some of it available, just by looking at the design of the software and interaction:

• Keep in mind the likely tasks of your application or function; feature all the important tasks, downgrade less-important ones, eliminate (or add barriers to) dangerous ones


• Focus on the important information. Show me the search results, or the map, or the incoming message. Advertising, upgrade messages, meta-data, network details, tips & tricks or almost anything else needs to be delayed, pushed towards the edge or hidden entirely.


• Help the user perform their tasks. When entering numbers, don’t let them type words. Limits are good, if they assist the user in completing a task. (We look forward to seeing robust input management return to most mobile browsers).


• Trust user data above all. If text has been entered, an address selected or an item scrolled to, that is more important than most anything offered by software.

And always remember, it’s a connecting device. The user on the other end of the connection has data as well, and it’s usually more valid than the best guess of your application.

Check out the Carnival of the Mobilists over at m-trends.

Yesterday, Gizmodo published a great comparison of four large touch screen communications devices, a.k.a. iPhone clones. While I’m not sure that “clone” is fair, certainly they are perceived that way by the customers and are being targeted at the same market. So they are perhaps intended to be iPhone “killers.” If they work. And it looks like the Instinct – which officially launches today on Sprint – does.

At Design For Mobile we will have Mike Lundy talking about getting Gizmodo’s winner, the Instinct, from concept to market. He’s Sprint’s UX lead for the Instinct, as well as many other Sprint phones.

As you might expect, with such complex products to manage, Mike’s been super-busy. He is relying on us to organize his talk for him, and we’re going to leave that to you instead. What would you like to see him talk about regarding product management, vendor relationships, product design, feature setting, or anything else about handset/carrier decision making?

Post your ideas in the comments, and we’ll gather them all up.