Skip to content →

6 Goals for Product Design Teams

Demand objectives from the people you’re working with.

Your job as a designer is to solve problems, not to make things look pretty. To do your job, you need to understand the who, why, when, what, where, and how.

People will try to hand you a spec or a list of requirements and say,”I’ve already thought about this a lot, just design it.” Don’t accept that. Insist, politely but firmly, that they tell you what the main goals of this project are. For any project, one can say, “if it doesn’t achieve X and Y, then we’ve failed”. Are you trying to sell or educate? Reassure or challenge? Are you encouraging exploration or optimizing for speed? Is this a one-time signup or an everyday task? Is the audience skeptical, or already enthusiastic?

People will suggest that you just use a lightbox, or just use the same styling that we used for feature Q, or just copy what Company Z is doing. These might end up being the best available solution, but you won’t know unless you push back to the defined objectives.

“OK, I like how Facebook uses that design element to solve X problem. Are we solving X problem, or is our situation different?” or “Yes, using that green button style would be consistent with what we’re doing on screen Y. But on screen Y the user is completing a one-time configuration, and in our case we’re trying to make a common task as fast as possible. Does it make sense to force consistency for completely different types of behavior?”

Shine some light on the design process.

I also call this, “don’t be magic.”

If you’re a skilled designer and an intuitive listener, you can probably combine what people are saying and not saying, deduce what they’re hoping to end up with, and make it magically appear on your screen. Voila! People will love you for this. It’s a critical skill for early-stage startups and design emergencies.

It’s also terribly non-scalable. It allows people to believe that they are communicating clearly when they’re not. It allows people to believe that design is “just drawing”, and that the thousands of implicit decisions you’re making about visual priority and color and scale and ordering are arbitrary.

You need to translate out loud: “So it sounds like you’re asking for X and Y, and you like the way that Company Z solves this problem because they have these similarities to us. And you’re looking to solve problem Q. Is that right?”

You need to explain your decisions: “I’m using this style because it emphasizes element A, which is the single most important action a user has to take. I’m deliberately not copying what we do for feature B, because the target user is completely different.”

Fight for what you believe in (pragmatically).

In past jobs, I’ve worked with designers who were at opposite ends of this continuum:

[tell me what to design and I’ll crank it out] < — — — — — > [change 1 pixel and you’ll destroy my masterpiece]

Neither is productive. And it’s incredibly hard to learn where on that spectrum is the most effective for you, your personality, and the organization you’re in. But you’ve got to try.

If you really believe that adding that fourth link will clutter up the UI, speak up and explain why. Feel free to express your doubts and the risks. And then, if your stakeholders disagree, pick your battles. Sometimes it’s worth it to fight to the death. Usually it’s not.

Be clear on what you will deliver, and when.

These are the questions that people will have but usually not ask:

  • How likely are these designs to change?
  • How final are the details like fonts, icons, and images?
  • Are you going to illustrate the interaction or will this be static?
  • Are you illustrating just the core use cases or multiple edge cases and usage scenarios?
  • Will everything be done, or ‘enough to get started’?

You’re better off listing out what you’re going to deliver in writing, with the above questions answered, and a date. It will feel like overkill. It will prevent a lot of misunderstandings. Use it as a checklist.

Recover and compensate.

If something comes up — and it will — and you are not able to deliver what you promised, immediately reach out and offer a plan for getting back on track.

Ask to make sure that’s the most convenient/effective plan for the people on your project.

Do not let a deadline slip without a word. Do not go off without a word, work in silence, and re-emerge 3 days later with all the work done. Speak up immediately so no one has to wonder or go looking for you.

Always be thinking about how we could be doing things better or smarter.

Our process is not there to constrain you, it’s there to help the team work more effectively. If it’s not working, you chafing at it and making yourself miserable will not help. Trying to sneak around the rules won’t help either. Complain constructively so we can fix it.

If you find yourself doing the same task repeatedly, stop and ask if there is a way to automate it or simplify it. If you feel like work you do is wasted, stop and ask why.

Or — if you did something awesome, stop and teach your peers what you did. Share successes. Rehash good meetings and projects, not just bad ones. Analyze why things went well, and try to reproduce.

Published in Uncategorized