Recent Blog Posts

I was in a game on my Android. I kept seeing this kinda-teasing ad for a game; I thought it might be relevant to me as a casual puzzle game player.

Finally, after hours of play, I clicked on the ad. Many users do this, in higher rates than on the desktop-based web. The advertiser paid for me to click this link.

What should the link do?

• Take me to a landing page directly related to the ad
• Already know my region and device
• Be optimized at least for mobile
• Have a call to action on the page
• Give me access to other information in mobile-accessible format

What did it do instead?

• Site home page, not landing page
• With no information about what the game was, not even platform(s)
• Demanded that I go through a two-step process to enter my region
• Took me to the product information page, coded in Flash

I regularly encounter people, or posts, that refer to all criticism as bad. That it stifles creativity, especially for us sensitive artsy designer types.

I could hardly disagree more. Criticism is a key part of discovering new ideas and working collaboratively. I am not brilliant enough to get by without help from others.

This opinion comes partly from my art school experience of all things. In general, I think art school was the best education I could have gotten. Not for the art per se, but for the criticism parts. After the first few years, getting the basics of the craft down, I had to (regularly, more than once a week) present my work, ask for opinions, accept them and act on it for the next review.

This taught me presentation skills, public speaking and an ability to think critically and rationally (not just emotionally) about my work, others’ work and what others have to say about mine. Yes, rationality, logic and business-like skills from art school.

Design criticism (and especially interaction design criticism) is a bit different, in that there are absolute truths and needs underlying everything. Art (at least the way I practice it) allows for individual interpretations. If your experience means you see something differently than I do, that’s usually fine.

For design, as a general rule, it is important that everyone understand the functions and the intent of the communications in the same manner. Individual interpretations that vary from the designer’s intent are generally a bad thing.

Design criticism is much like the peer review process. While scientifically-backed (theoretically, everything is confirmed by existing best practices or user research) there is additional help in having others… actually, Wikipedia has a great summary of this:

It is difficult for authors and researchers, whether individually or in a team, to spot every mistake or flaw in a complicated piece of work. This is not necessarily a reflection on those concerned, but because with a new and perhaps eclectic subject, an opportunity for improvement may be more obvious to someone with special expertise or who simply looks at it with a fresh eye. Therefore, showing work to others increases the probability that weaknesses will be identified and improved.

Even the simplest system I have worked on in the past decade is so complex I can’t hold the design in my head (and I am pretty good at this). The genius designer only goes so far, which is why my design documentation was created, and why I make myself stick to it.

Another way to think about this is in this posting about reviewing for journals:

In the early years, critique is about identifying holes and mistakes that make ideas less plausible. In the later years, critique is about identifying the germs of ideas worth development despite the current holes and mistakes.

In this sense, the value of critique is not unlike that of the concept reviews and brainstorming your may have done with the designers when they first came onto the project. Your critique (assuming the schedule allows for it) is not just to tweak the design, but to discover whether there is something totally brilliant or totally different hiding somewhere in there.

Design presentations to clients, and the critiques that inevitably follow, are all too often avoided, or are held with everyone defensively braced. Ideally, I have almost no big formal critiques, and share regularly. This doesn’t always happen though (scheduling, remote work, etc.) so the big review is still a part of my life.

I like to plan for them, and specifically ask for input from clients and others. I like to know my limits, and if something cannot or should not be determined by me or my team (e.g. there’s a good creative team at the client) I’ll leave that for them. And I prepare by putting together a good presentation, knowing the topic as well as possible, having answers or options for any decision that might need to be defended and bringing along any other designers who might know certain parts of the system better.

More often than not, clients reviewing design either focus on the wrong thing (the colors!) or seem overwhelmed by the massiveness of the whole project, and just sit back and let it wash over them. As much as it’s easy for me to not have to defend or revise anything, I like feedback, and need it to make sure the best product is going out the door.

As a reviewer, and especially as a client reviewing design you have paid for, here’s my ten tips for participating in a design review.

1. Look at the product. Review it as the designers wish you to. Feel free to take notes, but let the review be completed (whether a self-directed website walk through, or a presentation) before offering any feedback. Whether it’s a complex product, or your needs mean the presentation is out of first-time-user order, or the designer is just not that good as public speaking, you often will need to see the whole thing before you understand it fully.
2. Encourage everyone else to do the same. That is, take notes and wait till the review is over. Short circuiting this in meetings especially means you might not even get to the good parts, and spend the whole time arguing about the terminology of the signon process.
3. Follow up with details. Email is a great way to send more thoughts. Whether something didn’t occur to you at the time, or you are just a junior flunky and didn’t get a chance to speak up in the meeting, written commentary is useful. But do it quickly, before other changes are made or you forget the rest of what you saw.
4. Express your personal opinions on how you might use the product. User research is just lots of personal opinion and observation, codified, so if nothing else your opinion can be slotted into existing knowledge, and explained. The “worst case” is that it’s a brainstorming sort of point, and something else good can still come of it. Don’t, however, believe that your experience is necessarily of key relevance.
5. Relay anecdotes about use or understanding. Don’t spout pithy sayings “my mom couldn’t handle this” but do cite specific cases that seem relevant. Whether it’s the first impression of someone looking over your shoulder, or just what your heard some people say about the competitors product, that you worry this doesn’t do, it’s okay to bring it up if it hasn’t been heard before.
6. Quote solid information. Even if it’s “just” a marketing study or three year old use statistics. Ideally, the designers already know this, but if not it’s definitely time to bring it up. Even if they do, explaining that you have concerns about the design because of specific background information is a useful place to start a serious discussion.
7. Express personal opinions on style, aesthetic, etc. These might be trumped by brand standards, or consistency, or some other design needs. But bring it up. You might have found a hiccup in the standard implementation, or something else that needs to be fixed.
8. Everyone’s opinion is equally valid. Just opinion. If they have data to back it up, that’s different and usually trumps opinion. Even if you are the VP of everyone in the room, and authorize payment to the design agency, your opinion is still opinion. Your employees (and the vendor) were presumably hired because they are good at their jobs, so trust them to say useful things.
9. Allow the designer to counter your input. Don’t feel sad about it, because it’s not personal. If they have solid research, or experience, then think about trusting them on it. My guidance, whether reviewing other designers’ work or talking to clients, is “if you have a good-sounding story, I believe you.” Assuming you trust the guys you hired to do this work, you don’t have to understand what they say, but do make sure they sound like they understand what they are saying. Treat design like anything else you pay good money for, and trust their well-founded argument.
10. Review the changes later. Designers forget stuff, or don’t understand, or might make a new solution once they get back to the office. This is another reason you should write everything down. Don’t nag, but if you thought you understood that something different was going to happen, ask why. And feel free to ask for clarification; “we think” should be able to be followed up by “because of user research that indicates [something specific, with numbers].”

As a general rule, don’t be this sort of client, but do take ownership of the product. Offer the feedback that your position, background and knowledge of your business provides you.

A long-time friend of mine works at a major defense contractor, and is regularly providing me an interesting background in corporate telecoms. Most relevantly, his departent (company?) went wireline replacement some years back, so he’s issued a smartphone. They’ve had well-publicized lost computers full of employee data, so exercise a lot of control over their devices.

Here’s an email I got from him recently:

My Blackberry pisses me off in how it manages meeting notices.

If I don’t use my phone for a while, I might have several meeting reminders waiting for me when I go to use the phone. So when I pick up the phone, the first thing I have to do is unlock it by typing in a fairly complicated password. Then I’m immediately smacked with these meeting / task reminders.

99.9% of the time, I sitting in front of my laptop and I manage meetings/reminders on my desktop and not via the phone. But if even if I dismiss meeting reminders on my desktop, those meetings aren’t dismissed on the phone. Similarly, if I dismiss things on the phone, they’re not dismissed on my desktop.

So I hate the phone reminders. But that’s not even the biggest problem. The bigger usability problem is when I need to pick up and use my phone quickly. One example is when I’m receiving a call. And the other is when I need to make a call quickly.

When I want to recieve a call, I can pick up the phone and just press a button to answer without having to unlock the phone with a password. Typically I take all calls on speakerphone, though, so my desire is to press a button to answer the phone and then press the two button combo to put the phone on speaker. The problem, though, is that as soon as I answer the phone, I am FORCED to disposition each meeting reminder before the keyboard will allow me to switch to speaker phone. I MUST address each notice before I can go to speaker phone. Pisses me off.

And when I want to make a call quickly, the same problem occurs. I pick up the phone, unlock it with the password, and start dialing the number I want to call, only to realize that the phone isn’t even recognizing my typing because it wants me to first disposition the meeting notices. There is no way for me to make a call before I deal with each of the meeting reminders. Which is best exemplified by another common (and irksome scenario). ..

I’m on a conference call from 10:00 a.m. to 11:00 a.m. And I know that at 11:00 a.m. I need to go RIGHT into another call. So at 11:00 I hang up from the call I was on and immediately start dialing the next number I urgently need to get to, only to be again forced to deal with meeting reminders BEFORE I can make the call. I’m simply forbidden to dial until I give my calendar the attention it desires. If I end up being late for my 11:00 meeting, too bad.

Since when is my calendar more important than me being able to use the phone? Why can’t the meeting reminders wait?

I’ve had much the same opinion about some things my mobiles do, but haven’t had time to think much lately, so haven’t typed them up. But there are several lessons here.

First, end users matter. Some of his issues are a result of security software loaded by the corporate entity. Some of the others might even be surmountable by customizing the device. But it’s highly locked to him. He cannot do almost anything to his phone.

I did a fair amount of B2B (and government) work while at Sprint, and saw this a lot. Ignoring end users because they don’t make decisions. Yes, my friend cannot drop his service or change handsets, but his productivity is clearly impacted by poor user experience.

Second, you have to design holistically, or maybe, systematically. The Palm Pre I am using now is good at obscuring keyboard functions (including the mute and speakerphone functions, like my friend’s case).

My friend’s problem seems to be that every alert is modal. For the project I am currently working on, I almost let that happen by accident just by semantics. I called this subtle notification strip “alerts” in the documentation. By default the developers assumed that word meant they were critical and therefore modal. Luckily I (and the rest of the Little Springs team) was around and evaluating what SAs and developers were doing, and noticed this.

I have some detailed strategies aside from “constantly review” to correct this, but no magic bullet. Essentially, I say you need someone with a product-level vision, and I like to say that’s a dedicated designer.

For that product with the notification strip, it was blocked off for each and every screen and state wireframed out. Only a few things can be obscured by it, and those are carefully chosen; it’s okay if they are unavailable for a moment. This is my sort of tactic for holistic design, and so far seems to be working out.

Third, and maybe most importantly, people matter more than devices. I get similar behavior with my calendar reminders. I can get the same reminder:

• In google calendar as a popup
• In gmail
• Sent as an email to the corporate email
• Popping up on the phone

That’s not even considering that I have 2-3 computers I might be on, all with access to the same network of services. I could theoretically dismiss the same reminder TEN TIMES.

Sure, sure. I want it to be able to come up on all these, so I don’t forget about a meeting. I am forgetful, so need the help.

But I have to wonder why it cannot send a message to the network when you dismiss or snooze an alarm. Then dismisses (or snoozes) the alert in ALL your locations.

If I dismiss, that means I saw it, and should not have to be reminded again and again. I. Me. The person. Who cares about the the system?

Near the beginning of my book on design process are a few sections occupied largely with things not to do. One of them is on how mis-use and over-use of analogy is rampant and probably bad. It's short, so here it is in full:

Analogy – Interactive Design is Exactly Like Making a Pizza

No, its not. At all. Its also not at all like building a house. Or changing the tires on a car while its driving down the road at 60 mph. Or any other favorite analogy your leadership has used to describe the situation.

Sometimes, this analogy work goes quite a bit too far, and is a fairly bad thing. Processes, for example, are picked up from other fields and misapplied to interactive design. Inappropriate analogy or blindly inherited process encourages inappropriate process and methodology. Houses need blueprints, then foundations. Do websites?

It's time that interaction design (or even software development) comes into its own, and can be understood without arbitrary analogies.

Another key point in the misuse of analogy is the assumption that everyone else knows what they are doing.

...I live every day with the vague nightmare that at some point, someone more knowledgeable than myself is going to sit up and pen a massive screed indicating exactly where my work is shallow and fraudulent and rooted in lame, half-assed assumptions.
— David Simon

Yeah, pretty much everyone has those fears. Individually, organizationally and as whole fields. Architects, and builders and factories and pretty much any industry is chock full of seeking out improvements in their own process due to inefficiencies, inaccuracies and half-assed implementation. You can be an expert in your field and believe it is able to stand on its own. That said, there will be one or two small analogies in this text. Just don’t over use them.

But I missed another point, in that sometimes those other folks do indeed know what they are doing. If you can glean from them the kernel of truth, or the design principle behind their solution, you might learn something.

One of the things I have never really understood is the concept of the "Dashboard." It's something that was highly beloved by every Manager, Director, VP and so on at Sprint, so I heard it a lot. Had to design a few, but even then I never got the point.

Just the other day I am working this large, complex product design and the term comes up again. I had been ignoring it, or rather replacing "dashboard" with "portal" (which has a specific meaning to me, and is not a throwaway term). But something about the way it was said struck me, so I asked for clarification. And the answer was along the lines of "you know an airplane cockpit, with lots of dials and guages and meters and you can see the condition of everything about the plane at a glance."

Okay, I get that. But it also bugged the crap out of me. Because that's what 1960s airplanes look like.

A B52, designed in the 1950s, with all mechanical instruments for the flight controls, including eight engines.

And they look like that because that's the best they could do at the time. By the 70s even, there was a move to the MFD, or Multi-Function Display.

The same aircraft, with all the same systems, upgraded to modern displays.

With these (disregarding the backup instruments for safety) you fly the whole plane with a lot fewer switches, and by looking at anywhere from one to three large flat panel displays. How do they display all the information of the older cockpits? They don't. They use context to display summaries (and needed details) of the information currently relevant.

And while there's plenty of over-rides, it's mostly automatic context. As you approach the airport, these displays automatically tell you that, and switch from cruise to approach. And so on.

So when there was a break a few hours later, I told my client essentially exactly that. And I want to be clear that this all worked. I am not secretly ripping on a client for being dumb. When I went ahead and went off on my apparent tangent about cockpit design, it worked. It sparked some ideas about contextual display as they relate to our product which led (eventually) to a whole new IA, and solving the biggest issue before us.

Much like understanding the problem is key to starting to look for solutions, understanding the possible solutions is key to determining if they are valid solutions. If you have a similar issue, don't trust there will be a nerd for the subject area at hand, but do challenge yourself and go look it up. You might be surprised at how conventional wisdom is behind the times.

I am a designer, so like I guess a lot of people become accustomed to their job, I take the role of design for granted. When challenged, it's often a bit hard to figure out what it really means and say that clearly, without self-referential language.

Sometimes it's easy to use analogies, or quotes. Some years ago, as low-end clones took over the laptop market, some tech writer or other said, approximately, "Apple (and to a lesser degree Sony) design laptops, all others just assemble them."

I always liked that one, and even just said it the other day while trying to explain our role in a particularly large and high-speed process. But that is a bit overstated. Probably in ways that aren't helpful. Among other things, I think it leaves out some key job functions between design and assembly.

While there are many, many facets and phases to bringing any particular technical product to market, it might be best to consider three:

Design > Specify > Execute

I think we all know what is involved in specifying. Lists of materials, business rules, functional requirements, pricing models, data structures, storage, network access, and so on.

But already there is a problem. Specifying is not defined by these goals or documents. It can be generally defined as detailing what specific things (behaviors, features, buttons and materials) will go into the product, in what manner, based on known preconditions, and desired end states. Specifying involves finding an acceptable way for a system to work, and documenting it.

Designing also has tasks, and often the exact same tasks as specifying. But when you get to the core definition of how design works, the overriding principle is that design does not assume anything about the pre- and post-conditions of any one feature. Design considers, ... well, actually still the pre- and post-conditions, but those desired for the whole experience, from packaging to product to use, and how those are related to the needs of the expected users.

[Ed. Note] And "design thinking" is the practice of brainstorming many many options for the system, collecting concepts, and assembling the ideas into a small number of concepts to explore. Amusingly, in my design education there were two classes on this, called "ideation", and the rest was the sort of problem solving and communication described here. — Barbara

Design for Marketing, and People

Consider for a minute something that a lot of people tend to confuse with the type of design I do, marketing and segmentation. A lot of folks seem to think that design for products (and usability research even more so) is some sort of glorified version of deciding which market segment to appeal to. But that marketing – without design input at least – simply creates those assumptions, and the result is marketing-driven specifications. "Colorful and fun, for children" or "Language to appeal to the teen market" or "Must meet $129.99 price point" are all things I have seen result from marketing-driven specification.

These may be fine to kick off a project concept and get funding, but they are not design goals because they do not drive the overall approach to the product. As one example, talking in a teen manner – even when executed well, which is difficult and rare – is always a failure if nothing else changes about the product. And I don't mean "cool teen graphics," but the tasks available, the manner in which they are approached, the integration with other products and services which engage the audience already, and really the entire experience. Design (at least design for user experience) focuses on behaviors more than demographics and fads.

Design for Processes

Design is not in opposition to marketing, nor does it supersede marketing. And neither does design override or disagree with the specification people or processes. Instead, it works hand in hand with all of these phases.

Design, at least the way I do it and write about it at great length, supports marketing, by looking at the perceived needs, the competition, and the users, then creating personas, design goals and other deliverables to help everyone understand the true needs and limits of the product.

Design supports specification by, first, the creation of these goals and understandings; the key assumptions about the product become more clear, consistent, unambiguous and defined. But we also typically perform the traditional task of design and draw things. Rough, conceptual things, that can often be turned directly into specifications.

Just the other day yet another analyst came to me, shocked that the annotations to the side of my drawings were in his language. He simply copied many of them into the requirements document. This is not fortuitous or incidental, but entirely intentional; it is what we do to best support the process, and the specification people to get the product built on time.

Design for Execution

To the last phase of the miniature chart we started with, "execute" in traditional models accepts specifications, and builds (whether with CNC mills or code) the product. But even here well-run design processes can add value and reduce troubles.

Execution-phase people – developers, architects, tool and die makers, QA, etc. – are not robots. We're not talking about the assembly line, or the webserver, but about the people who build that. And they are people. And products are complex, so pretty much cannot be specified perfectly (or, alternatively, cannot be held in a human's brain when sufficiently specified). An absolute, rules-based system does not work, and there are gaps, cost over-runs, errors and rework.

If you are lucky. If not, there are missed deadlines and angry customers. Or no customers. Design can hold a role in documentation, even. A simple way is to carry those early goals created with marketing through the rest of the process. But the documents can be designed as well, to appeal to the needs of the execution teams. And to express the broad vision, and core needs of the product as something inherent to the specification and design documentation.

Aside from creating all my own design documents like this, at Little Springs we even get work on projects that are about nothing but re-designing and re-writing complex, reusable specifications documents.

Design and You

While this is what I do, it doesn't mean pretty much everyone can't do it. One of the biggest drivers to being a good designer of technical systems, aside from the usual good-work-ethic stuff, is internalizing the process and having enough knowledge of the domain. I am better at designing mobile interfaces and account management systems, because that is where my design experience lies.

You could get there also and empower your processes with a design mentality, but I do think "Design Thinking" with capital letters, as espoused by management process types, misses the mark rather widely. Not sure where that came from, but as an art school graduate, designer for years and process-oriented guy, it makes not a damned bit of sense to me.

[Ed. Note] I think design thinking is about "getting the right design" and Steven's discussion is about "getting the design right." Both are necessary. — Barbara

Among other things, design does not have to be "designy." It's not clean lines and pretty colors. Good factories have well-designed processes, but (at first glance) looks like pretty much all other factories, and not like utopian Sci-Fi future factories.

Design can be informed by creativity and aesthetic and even opinion, but I believe this is not what it is at its heart. Design is about looking at problems, or the world, Holistically (other keywords, like Systems Thinking also lead useful places). If your project seems bogged down in minutiae, hire a designer who thinks like this, or back up and try looking at the problem anew, without its initial assumptions.

Consider how your product lives in its world, and how it changes the lives of the users, and how it changes their interaction with the world.

For a while there, designers and developers could ignore screen and pixel size, at least for "high end" devices. Let's be honest here, "high end" meant iPhone-like: touch or multi-touch screens, high end Webkit browsers, and 320 x 480 pixels.

That time is now over. To our mind, it really wasn't here in the first place.

Why is the time now over?

1. Android has matured a bit, and manufacturers are putting it on everything. Consider this ARCHOS Internet Tablet (800 x 480 pixels, 4.8 inches), this Vega Picture Frame (1366 x 768 pixels, 15.6 inches), this 7 inch tablet, or the nook's 3.5 inch screen with what looks like a 5:2 aspect ratio
2. Even Palm's WebOS devices will not be consistent, with Pre's pixel dimensions matching the iPhone's, but Pixi's are at 320 x 400 pixels (80 pixels shorter).
3. Normal Android phones, such as the Motorola Droid at 480 x 854 pixels, no longer have a predictable size. Who knows what the next devices screens will be like?
4. The Motorola Droid's pixels, like the ARCHOS pixels, are much smaller than the iPhone's; bitmaps that work well on one may not on the other.

We wrote Photoshop layout is not your friend in March; this new array of high-end devices forces a choice: design for iPhone only, or start designing for multiple screen sizes.

If you're designing Android applications, you have some tools available to you. The Android Developers' Supporting Multiple Screens gives designers and developers a way to deliver the correct layouts and graphics to the correct devices.

For now, however, Android doesn't really support the full array of screens upon which Android is found. Here is what the document's Range of Screens Supported section says about device support:

The Droid is there, as a high-density, normal screen. The iPhone (were it an Android) and early Android phones are medium-density normal screens. The ARCHOS is a medium-density large screen. The nook and the Vega are ... not in the table at all.

Android's support of screen issues is incomplete, but many steps better than previous cross-device platforms like browsers and Java ME. Despite this, many developers have simply ignored the possibility of different screen types. My favorite example is the Fuzzy Clock widget, which is supposed to take up 25% of the screen with a single line of text. Apparently they used a single-sized bitmap font because on the Droid, the "glanceable" clock has the equivalent of about 8 point font. Not at all readable.

And frankly, I don't expect Apple to keep to the current screen dimensions. I don't have any inside information, but they will make a smaller screen or a bigger screen, or a higher-density screen, or probably all three. So even those of you focusing just on the iPhone may want to look at your process in the next few months.

The hardest type of applications to design for multiple screen types are games, as many create mazes, game boards, and levels for a specific aspect ratio. If your application uses scrolling or other pagination techniques, however, you can probably design it to comfortably manage a wide variety of screen sizes. (But all bets are off for supporting the Nook's screen, which will really want to scroll laterally, not vertically). How? Go read the resources linked above in this article. Or hire us.