March 30, 2011

Let’s design a car.

Gather a few people you know and ask them to help. Then, ask an actual automobile designer to join you.

Ask everyone to sketch out a car, except the automobile designer, and then share them with each other. You’ll probably get a lot of “I like that” or “I don’t like that color” or “Wow. Different.”. Once you’ve discussed let the automobile designer critique. He would probably ask questions like, “Did you take aerodynamics into account with your design? Fuel efficiency. Difficulty to build. Parts availability.”, “Why did you make the windows that shape?”, “How would you pitch this design to engineers?” and so on.

Who would be able to answer? And answer adequately? No one.

Now, I know nothing about car design. I know what cars I like and don’t like. If I was given a sketch pad I could probably draw an outline of a car with some detail. But I do drive a car regularly. Does that qualify me? Probably not.

When it comes to product design, especially with mobile applications, it seems everyone wants to be involved. Of course, certain people should be involved. You’re going to have project managers, product managers, developers, IT people maybe, managers, and so on. However, one key component is missing with all of these people’s titles. Designer.

Design Feedback

I love hearing feedback on my designs. I welcome it more than probably necessary. But with feedback, I like reasons. “I don’t like that color” isn’t going to fly with me. Within a few minutes of a feedback session or over email it’s glaringly obvious who uses mobile apps (drives a car) and who designs mobile apps (our automobile designer). And sometimes you’re not even lucky enough to have someone that actually uses apps or the device you are designing for in general. But they’re involved in this product. Probably because of seniority or fuzzy lines between departments. Good luck. If you can find a book on social engineering I suggest picking it up and reading it as fast as possible. You’re going to have to do a lot of convincing and compromising without upsetting said person.

‘We Want to Change, Add, Remove (This)’

These are the worst words a designer can hear. First because they used ‘we’, meaning everyone else but you wants to do and there’s no other option. Second, it’s probably something that totally disrupts the current design plan. Third, the savior item. The worst. The savior item is the, “The guys upstairs don’t think users will understand (insert option).” or “It’s too similar to other apps. We should stand out.” Now I might agree with the last one if the similarity is based on function and not design/UI. Otherwise, it’s probably something that will end up working against you and confusing the user. Remember, these statements are most likely coming from someone that doesn’t have user experience so of course it’s confusing to them. I’ve found that if these ideas go through somewhere down the line they will try to make it look like it was your idea and that it’s bad. Keep notes. Save emails. Especially your responses. Especially the ones that say, “I think you’ll find as we progress with this app that this function will become confusing and unnecessary.”

One Step Ahead

One thing most non-designers aren’t thinking about is impact of function. Maybe the developer or IT guy is thinking about this, but the manager-esque crew probably isn’t. Impact of function is what I like to call the Butterfly Effect of Design. Think back to the car metaphor. Remember the questions about aerodynamics, fuel efficiency, et cetera? That’s impact of function. A cool looking modern, blocky car is most likely going to have terrible wind tunnel results. Since we weren’t car designers though we didn’t think about that. The same applies to mobile design.

The biggest problem I see during a design by committee process is product ignorance or UI ignorance. How this is usually presented is when someone wants everything to fit in viewable area of the device ignoring that scroll exists or that pagination exists. Why? Because that’s the way they are viewing mocks and wireframes. They are unaware of this whole other world behind or below the current screen. This ends up causing clutter. As soon as you try to explain and take pieces away you’ll receive a firey email when you send out the next round of mocks. “Where’s this?!” “Where’s that?!”

Designers are creative. With creativity comes imagination. When someone can’t imagine certain items existing in a non-viewable area because you’re looking at a flat image of a screen, they’ve become toxic. Get them out of there. Either don’t include them in the regular meetings or dismiss them from the project all together if you can. They will do nothing but hinder the product.

‘If You Can Dodge a Wrench, You Can Dodge a Ball’

This post is in no way a solution to the design by committee problem. It will always occur. Simply, I’d like to share the experiences I’ve had. I can say this though. It gets easier. You’ll learn to deal with these committees as you progress. The subtitle says it all. If you can get through a really rough design by committee situation, you can get through the rest. You’ll be better for it as well. Just know when to pull rank, when to say no, and when to go to your boss. Don’t do any of these too often or you’ll look like a rookie and you’re supposed to be the expert.