Prioritize their problems over your solution

Standard

As designers, we tend to get wrapped up in our own little worlds. Forgetting that design is problem-solving, we only seem interested in sophisticated tactics or cool solutions.

Last year I was invited to take part in an event called UX for Good. The concept was that we could save the world by applying user-centric methodologies to solve problems like homelessness and urban violence. I know a bit grandiose, but I think there is a kernel of truth there.

I was in a group with people from Ceasefire, an organization that uses a public health model to reduce violence in high-crime neighborhoods. Their model is very successful at the local level because their people know who’s who and what is going on. More importantly, they’ve seen first hand what works and what doesn’t.

The group split up into teams to come up with ways to help Ceasefire indirectly so they don’t need to change their own tactics and focus.

One thing that works well is when there is a safe haven, a neighborhood place where kids can get away. It works because Ceasefire staffers negotiate with gangs to ensure they’re off limits. So our task was to come up with ways to increase the number of safe havens.

First, we assumed these safe havens need to be compelling to attract kids. One idea was to create a place where they could express themselves with activities like creative writing, street art etc. It was like a little cultural center. Our contact (or stakeholder) just nodded. He seemed indifferent. So I asked him what kinds of things he’d have. He said, “hot water, video games, and a TV.”

It was so mundane, that it literally turned off a couple of my teammates. But it dawned on me then and there. The problem with safe havens isn’t that they’re boring. It’s that there aren’t enough of them. The discussion really wasn’t going anywhere with our stakeholder until we started exploring ways to make safe havens easy to replicate.

As designers, we need to spend less time trying to impress with technique and more with outcomes.

Prototyping is like sketching

Standard

When it comes to design, I maintain the philosophy that just about everything is a prototype, until it isn’t. That drives a lot of people nuts because most of us just want to see the finished goods. If you’re part of a broader team, you need to see some sausage making in order to make informed decisions.

Prototyping as a term can be as useful as it is problematic. It’s vague and open to too many interpretations – kind of like design. In cases like that, I find it’s better to use an analogy to tell people what you mean.

I recently started using the analogy that “prototyping is like sketching” to explain my philosophy[1]. Trouble is, people misunderstand sketching too. When people see a sketch, they think, “unfinished”, but completion isn’t even the point of a sketch. Sketching, like a prototyping, is for communicating something vague not concrete. Why would you want to do that? One good reason is to explore your options with others.

Beware, most people don’t appreciate the process of moving from ambiguous to precise. “Done” is often rewarded over useful and usable. Ultimately, it comes down to the context in which you present things to people. No one likes to see unfinished work, but they do like to explore options.

[1] I want to give credit where credit is due. This dawned on me while attending a workshop on sketching for product design by Kevin Henry, an associate professor at Columbia College.

Consensus now, or argue later

Standard

I have worked on a lot of products in my career and peoples’ ability to balance logic and emotions is woefully inadequate. People approach product design and development as if it were just a series of approved steps. It’s not. Design evolves. It should start from a very logical place and morph into something emotional. The key to a successful design is managing that transition.

The time to be logical is in the beginning, before anyone has had a chance to see anything. Use this time to build consensus, and not just about goals and objectives. Think ahead of the emotional responses you are looking for – from the team, the stakeholders, and especially the end users.

Don’t move forward with the design process until you’ve done this, or you’ll be sorry. As people start to see things, the design becomes more tangible and their reactions more visceral. Unfortunately, most people can’t articulate their emotional responses, especially when their expectations aren’t met.

Achieve consensus around the emotional responses you are looking for, and be specific. Do this upfront and don’t show anyone anything until everyone agrees. Having a common language around emotions will enable you and everyone else involved to communicate more effectively as the design process evolves.