Equal partners: Designers and Product Managers
Design Process at Asana Vol. 2
Design is not just a designer’s game. The design process has many levels, and many players on the field. It takes a whole team to design a successful product, and I’ve been lucky and privileged to collaborate with an amazing group of product managers at Asana.
What’s special about product managers (PMs) and designers at Asana is that we are equal partners. At any given time, I’m as much of a stakeholder as the PM is. If I feel something could be solved differently, or I don’t believe we are going in the right direction, I can (and am obligated to) voice my opinions, and, if I have them, my solutions. It’s great and crucial to create a dialog around the issues in a design. I’ve been convinced as many times as I’ve convinced others, and I’d like to believe it has always been for the best.
PMs come in many different varieties — this is wonderful! Every project can be tackled in many ways, and benefits from a broad spectrum of skills and viewpoints that can solve every problem. Each PM has their own management style, and though it may differ a lot from one another’s, what remains constant — and what is key to a successful outcome — is a structured process. I’ve worked with many PMs on a wide variety of projects: the dashboards feature, our complete product redesign, email notifications, Android and iOS apps… Every one of those had diverse goals, needs and constraints, but started with the same strong foundation.
Introduction to the Project
There are many ways to get introduced to a new project. It can come in as a document, a task in Asana, or an in-person chat. The contents can range from a premature brief before any research starts, to a more detailed document where research has already been done.
The introduction usually takes place a couple of weeks before the project starts. I find this really helpful because it makes me aware of what I’m going to be working on next, and reminds me wrap up the current projects; or allocate time for both, if I’m going to be working in two at the same time. Similar to an actor preparing for a new role, it also gives me some time to get in the right frame of mind and start thinking about design research I might want to do, or people I might want to talk to for ideas.
In-depth Briefing
Then comes the juicy in-depth briefing. Usually a meeting, around an hour long, where we dive in. The contents can be divided into three blocks:
The Cause: Why are we doing this?
What’s the reason behind this feature, or this redesign, or this project? It can be something the users have asked for specifically, something we think the users need based on our studies, or something that requires iteration because is not meeting success metrics.
The Margins: What are the constraints?
In an ideal world, we would have endless time and resources, but that’s not realistic. I love knowing ahead how much time we can allocate to a project (including research, design, engineering), so if we have wild ideas that don’t fit the budget we can save them for the future.
The Idea: What needs to be designed?
Depending on the project and the PMs, this can go from a detailed briefing to a blank check. For me, both scenarios are welcome. If we agree that the proposed plan is the best way of solving a problem, I can focus my time on fleshing out the idea. But most of the time, I question the plan (this is both important and healthy), because my perspective on the matter is fresh and new. This might lead to modifications on the briefing, or simply new interpretations of it, because an initial briefing is never locked down, no matter how detailed it is.
If a PM wants to let me come up with concepts first, I get to propose solutions from scratch, bouncing ideas back and forth with them until we get a proposal we like.
During the in-depth briefing, while the PM is explaining the project, I listen carefully and rarely speak right away. I need time to get it all in my head, to let the design be built and settled in my mind. Once I feel that I understand The Cause, The Margins and The Idea, I start talking. More often than not I find myself asking: “Why are we doing X when we could do Y? Why are we having this problem at all? Is this actually a necessity? What’s the root cause of this? Are we over-thinking?”
This helps me figure out if we’re missing some possible solutions that are currently out of the picture. Thinking at a higher level gives me perspective on how the design will interact with the rest of the product, and what the users will experience.
Designing and syncing
This is when differences between each PM and designer bubble to the surface. In addition to weekly or bi-weekly team meetings, stand-ups or snack-syncs, we all use Asana to know what we’re up to. Some PMs love having everything documented as tasks, with every little bit of design accounted for as a subtask. They don’t actually want you to design every part individually and complete its task; it’s just their way of listing what needs to be done.
Others give you a general task and some other info for each milestone in the project, letting you decide work freely around the design.
And then there are the ones who put due dates on the tasks. Again, not locked, just a suggestion so it’s easy to check if we have a good pace or we need to re-calculate our dates.
And some others just let you know in person what are the estimated delivery dates, and let you adjust and make up your own schedule.
On the other side, designers also have similar styles: some structured and some more organic and free-spirited. Those styles might be important when you pair PMs and designers. Though we all get along really well and can collaborate with each other, different combinations of personalities are perfect matches for different projects.
Once we start coming up with mocks, we go through Design Crit. After that, the relationship with the engineers takes over. But that makes for another post…
With time, I’ve gained a deeper knowledge of the product and our users. Sometimes designers easily fall into a trap of over-designing, early optimizing, or going for solutions that are unnecessary, complicated, or make sense only to very tech-savvy users. And having a healthy relationship with the PMs as helped me many times to get to the best solution.
Those are some of my favorite moments at work. It feels great to come up with a clean design so seemingly obvious that it requires no explanation. When you show it to others, they might not even seem impressed because they think “of course it’s that way, how else could it be?!” I’m pretty sure I stole that line from Jonathan Ive speaking in the film, Objectified.
Questioning what we’re doing is an ongoing process. At every step of the way, and especially as complications arise, I keep asking myself if we’re on the right path. It’s better to pivot or start over than go all the way through with a bad concept.
This is, in a nutshell, the process and the interactions we have with our PMs at the beginning of each project. This allow us to ship new designs that make Asana better with every iteration.
To get to that point, I’m never alone. It might sound sentimental and cheesy, but it is the truth. The Asana PMs always provide, whether it’s data insights, user research results, thinking through solutions together, or answers to my crazy questions.
PMs are the coaches of the team. They can see the whole field, how the game is going, how long is it going to be. They design plays with enough room for every player to improvise and they make sure that each member of the team unleashes its full potential.
If you liked this post and want to know more, you’ll probably enjoy my previous post: Design Process at Asana Vol. 1 (Crit).
Special Thanks to Amanda B. for spellchecking and editing this post.
