Product Design: Breaking Down Your Project Work
Courtesy of Unsplash
I see it all the time and am guilty of it myself. A designer gets a new project to work on, the wheels start to spin, ideas start coming, and what we see in our heads isn’t sketches, flows, or component design, it’s a shiny, beautiful, well-designed product with happy users. Which is all well and good, and should happen.
What happens next is where the problems start. Fire up the computer, open Figma (or insert your favorite design tool here), and start designing that shiny product you saw in your head. Sometimes the run and gun method works, but most of the time it creates a lot of re-work of your project because you’ve missed some key touchpoints along the way.
One of the most important things to call out before we get into the method, is that when you design this way, you tend to become more emotionally attached to the project and the work. While I agree that there should be emotion when creating, emotion should inspire, not be the driver. The data, use cases, user stories, and metrics, etc. should be the diver.
It Starts With Emotion, Ends In Fear
A majority of companies I’ve worked with in the past, the Project Manager (PM) would run the team on the project, putting a brief together to explain the proposed work and to get alignment and give direction. Designers would then take the brief and go heads down designing, without much context or understanding to the root of the problem. They would create something they believed to be great, and would pop up a few days later to critique it with the team. The designer would come in enthusiastic about the awesome design, and then…. the questions come rolling in. Most of them tough to answer, leaving the designer desperately searching for a response to preserve the emotional attachment to the work. This would leave the designer feeling defeated.
Further, the outcome of sessions like that can have designers showing their work less frequently, to avoid those uncomfortable moments, and instead relying solely on their PM to give the thumbs up or down on whether the work met the experience standard and ultimately is ready to ship.
Like dominos, the pieces will continue to fall. By not sharing work in critique the designer misses out on opportunities to align with the overall product vision, making sure they are using the correct design system components, and finding new opportunities to make the experience delightful.
This can leave the product feeling disjointed. And in turn, everyone suffers — the customer, the designer, the design & product team, and the business. All because the designer feared the feedback due to the emotional attachment to the work.
So how can it be solved?
I take the perspective that designs are created by us, for others. The emotional attachment should be around the problem, not the solution. By loving the problem, and being empathetic to the customers and business, the designer frees themselves up to explore many solutions, not just the one they saw in their head.
One way to approach solving this is the designer needs to break down the work into more manageable chunks so that they get feedback earlier and at a quicker cadence. They also need to let go of their fear of showing “unfinished work”. Showing work at its earliest stages helps make sure that the work is on, and stays on, the right path.
Here are 4 phase of a design process to get the designer started:
Functionality — What does the product need to do?
Information Architecture — Hierarchy of information and flows.
Interaction Design — What components best fit the needs?
Visual Design — those pixel-perfect frames we love so much.
And, remember to share with your team early and often.
Coming soon — easy ways to share work and get feedback in realtime.
Functionality
While the PM brief typically covers the majority of “what we’re doing and why”, not every designer can easily make sense of the brief or the work that would be needed to solve the problem, because the documents can tend to be broad, unorganized, or have tons of information that isn’t necessary for the designer.
So in addition to the brief, each designer should create a simple project overview that clearly and concisely states what the problem is, why it’s a problem, user data, business impacts, etc.
Project Plan: Use this template to guide you.
While It seems like a duplicate effort, designers writing their own project plan helps with communication with the PM and engineers, gets alignment on the work, and provides the other designers with the right amount of context so that they can give appropriate feedback in critique.
Instead of designers jumping into the work assuming they understand, with this framework, not only do they understand it better but the designer is able to speak clearly and confidently about what and why they are doing the project. Once the project plan is ready, review it in the critique. That’s right, critique the project overview. This gives all the designers (and anyone in attendance) a chance to challenge the designer on the proposed project. If the designer can’t answer questions around the work, then they have an opportunity to get clarification from the PM or dive deeper on what they needed to do.
This is also a conduit for the designer to do early product shaping, getting stakeholders bought into the direction before the designer moves a pixel on the screen.
Stage Gate: At this phase, the designer will want to review the direction of the solution with leadership for alignment and agreement. Ideally, this is part of the Discovery work and the solution would inform the brief and be prioritized to your teams roadmap. Coming soon: Dual Track and how to do Product Discovery and the double diamond method.
A side note: Designers spinning up project plans is not a replacement for a PM brief or Discovery work. If you’re in a mature product org that values and prioritizes Discovery, the Functionality phase is done collectively with your squad. By the time you get to the “Design it” phase your team will have collaboratively come to a solution and validated it.
Information Architecture
Information Architecture is an immense and nuanced subject, and here I’m addressing it in context solely to how the product designer should be thinking in terms of all the potential user flows that would arise with the proposed solution. See links in the resources section for a beginners guide to IA.
IA is arguably the most important part of the design artifact phases. This work should detail how the content should be laid out on the page as well as document all error states and edge cases the team can think through. In this phase, the engineering team should be heavily involved to scope the feasibility and effort, and in turn, begin their planning. The more eyes on the work at this phase will help identify gaps and states that may be missed. Getting the PM , Engineering Manager (EM), and stakeholders bought in at the IA level will help to avoid major rework in the later phases of the project.
Output would look like flow diagrams, wireframes, service blueprints and low fidelity prototypes, all to be critiqued with the full team. At this point of the process, there will likely be a few rounds of review with the team, prior to review with leadership. Bring the work to leadership once you’re confident you’ve accounted for all the flows and scenarios.
Stage Gate: At this phase, the designer will want to review the architecture and flows with engineers and stakeholders for alignment and agreement on the effort.
Interaction Design + Prototype
In this phase of the design process the designer is looking at what components are being used to create the interaction experience within the flows. An example would be something like, “are we using a drop-down with listed options or do we expose all the list of options?”, “Is a primary or secondary button necessary”, or “How does this tile scale when clicked/tapped?”. The level of fidelity is important here. You don’t want too high of fidelity that distracts the audience and focuses them on the aesthetics. The use of prototypes here is paramount to get a feel for how the interactions feel on different screens and to assess their effectiveness.
The Design System team should be heavily involved in this part of the review process to gut check that you are using the right components or if there are better components to use to execute the design. At this point of the process, there will likely be a few rounds of critique with the team prior to review with stakeholders/leadership.
Now is the time to create a mid-fidelity prototype to put in front of users on a platform like usertesting.com or dscout.com. Once the flows and interaction design have been validated, bring the work to leadership with supporting data. The designer needs to be mindful of the level of fidelity as they will want the team and leadership to focus on the interactions that you’re proposing.
Stage Gate: At this phase, the designer will want to review with design system team and leadership for alignment and agreement.
Visual Design
In the final phase of the design process the designer is delivering polished high-fidelity designs and prototypes. This is the final check that designs are pixel perfect and all appropriate design system (DS)components are being used. If new components are introduced, the designer needs to make time to pair with the DS team to document and execute the new component (reminder: this process should be started at the interaction design phase). The prototypes and final designs should also be used in pairing with engineers. It is imperative that the designer has at least a functional understanding of engineering, and equally the designer should be coaching the engineer on what is good design. This is will assure the engineers have a fundamental understanding of why the designs have been created in the way they have and will help the designer understand effort and capabilities. Once the team has agreed that the work is in a shipable state, then it’s time to review with leadership and stakeholders and do a bug bash.
Stage Gate: Since this is the final stage, this where review with leadership is mandatory.
Bonus: Critique Questions
Below are questions that I use to guide the critique at the various stages. These not only help facilitate the critique but help the designer working on the project to predict what questions are asked and how they would answer, making them more prepared for difficult reviews with leadership.
Functionality:
(Ask yourself) Do you understand the problem and context of what is being solved? If not, abstain from feedback.
Are the concepts solving the problem?
What is working about the concept(s)?
Is there anything that isn’t working? Why?
What opportunities do you see?
Open questions for the designer:
Information Architecture:
Is this IA helping to solve the problem?
What is working with the IA?
Is there anything that isn’t working? Why?
Does the hierarchy align to customers needs?
Do the current flows make it easy to anticipate the next action?
What opportunities are there to simplify the flow?
Open questions for the designer:
Interaction Design:
What is working with the interaction design?
Is there anything that isn’t working? Why?
Are the interactions easy to understand?
Are the interactions what a user would expect?
What opportunities are there to improve the interactions?
Open questions for the designer:
Visual Design:
What is working with the visual design?
Is there anything that isn’t working? Why?
Do the visuals align with brand?
What new components are being proposed?
Are there other components in the system that can be used?
With the design in place, does the IA and ID still work?
Open questions for the designer: