Recent Blog Posts

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?