Pardon me while I rant a little bit here. But I’ve seen this situation one too many times:
New team sits down. Project sounds great. Everyone is excited. Requirements aren’t really clear, or totally defined, but who needs ’em? We’re AGILE!
Feeling eager, the designer rushes off. He begins interviewing users. She does a competitive analysis and digs up loads of useful design patterns and informative data. Wireframes begin to form. Big questions are asked. Then even BIGGER questions. Soon the designer(s) on the team are questioning the fundamental nature of the internet.
A deadline looms. The wireframes lurch forward, beautiful but awkward like all new life. The designers love them like flat, digital children. They iterate a few times internally, then share their brilliant direction with the team.
And everyone else is confused, then irritated. They might be beautiful children, but they have nothing to do with what the team has set out to do or the problem it’s set out to solve. Back to the drawing board.
I’ve seen this happen so many times it makes my eyes bleed. There’s lots of problems here, some of which are sort of not the designers fault. But a lot of them are.
Please. Please. PLEASE! Pay attention to the scope of the project you’re working on, damn it. You are part of a team, to achieve a goal, to solve a specific problem. If you don’t do that, you’ve wasted everyone’s time. More importantly, you’ve wasted YOUR time. You could have been making something horrible easier to use for someone, but instead you have a drawing and not much else to show for it. I know, it sucks. No matter how great the design thinking that went into it, IT SUCKS. That’s what makes me so angry about it.
So much potential of so many designers—wasted.
Please, don’t let this happen to you. The world needs your help.
If consultants make this mistake, it’s a disaster. It’s late nights with no pay, or losing a client. Working in-house, it’s easier (although not always). Okay, we learned a lot! Let’s iterate!
And certainly sometimes you have team mates who struggle to articulate direction and requirements and the problem you are trying to solve. Sometimes the only way to facilitate that communication is to draw something—anything!—so they can start to tell you what they really meant.
My point is more about self-awareness. Before we rush off into happy pixel funtime or design wireframe happy land, we have to take a breath and make sure we understand what we’ve been asked to do. We must make sure we understand the needs of those around us. We say we are experts on understanding people and their needs. When we turn around and don’t understand the person we spend most of the week with? It discredits us in their eyes. “How well can they understand our users if they don’t even understand me? And I’m right here!” This is more often a subtle, subconscious loss of trust over time more than someone overtly thinking this.
We may need to be assertive and do things that supposedly aren’t “design activities” to make sure we understand what we’re getting ourselves into, such as writing up assumptions or requirements. If you’re on a project with ambiguous direction or unclear requirements, don’t let it slide. Don’t assume someone else will figure it out. Ask for clarity. Writing up your understanding in the form of user scenarios or short one paragraph narratives is a great way to get people thinking concretely about what the heck they are doing. It’s also a completely normal design activity that most of the time shouldn’t step on anyone’s toes.
When in doubt, ask why. I’ve heard it said countless times. The best designers ask why. Why are we doing this? Why are we here? Why does it need to be that way? Why am I drawing this screen exactly?
Take a step back and ask yourself. What is the most important thing you can achieve here? What’s the most important thing everyone could miss?
Go after ambiguity like a honey badger meets 0007.
Kids make drawings. Designers motivate colleagues to build better things, for the benefit of everyone.
