Project management basics for Product Designers
The 6 important decision-making check-posts within a product design project life cycle
Not a secret sauce but a milestone-based approach that optimises time, effort and cost by bringing better transparency and accountability among the stakeholders.
In the agile world, ‘jugaad’ is often the way to go by bypassing the ideal processes. While that's usually the norm among startups, skipping certain key decisions may lead to disastrous results adding irreversible inferior changes to the project. It not only demotivates the team but is also a waste of Effort, Time and Money.
This article presents a linear milestone-based model with decision-making check-posts of a typical product design project life cycle. The idea is to encourage the right stakeholders to make the right decisions at the right time.
The primary principle
Moving prematurely into creating solutions without the right understanding of the problem, and the necessary alignment with the key stakeholders is one of the common mistakes while moving faster with projects.
At a macro level, product design projects have a linear flow. It starts from understanding the vision first, forming the right strategies second, and planning the tactical details to execute the design interventions.
When people mix up the above linear order, it invariably creates confusion and misalignment within the team. It is a mistake a lot of people make by starting in the tactical phase and working backwards. Because, tactics are to be built on the foundations of a clear strategy, and strategies are built on the foundations of a strong vision.
A clear vision is what drives the quality of the outcome, and it is singular and directional in nature. So, if it deviates from the strategy or the tactical stages, it makes the strategy made for the previously referred vision defunct. When the strategy itself is invalid, any work done on the execution side(tactics) will become irrelevant.
The following illustration shows how two different visions, would have completely different tactical approaches toward delivering the outcome.
This is why it is important to freeze the decisions made at each level to avoid rework. Sometimes, changes are inevitable, but this brings visibility to understanding where things went wrong, and who was accountable for it. More importantly, it will inform the team about valid reasons for any change in the proposed timeline and the scope of work.
Understanding the macro stages of a quintessential product design project life cycle
In this proposed method, there are six stages/phases within the life cycle of a typical product design project. Each stage has its share in contributing to the success of a project, as well as to designers' career growth.
Designers especially in their early careers do put a lot of focus on the 3rd stage(design execution stage), but the other stages become extremely relevant as they progress into leadership roles.
The 6 decision-making check-posts (Milestones)
Each stage of the design project is expected to have its own key results(output), and these results have a high influence as they become the primary inputs for the following stages. This is why they are called milestones that need to be met before moving further. Any major error in those early stages will completely deviate the team from moving closer to the final outcome
Find below the sub-stages and the expected outputs at each stage for this proposed model of a product design project life cycle. The objective is to ensure the right decisions are frozen before we move ahead to the next stage.
Milestone 1: The outcome agreement via project statement
The first milestone should be an explicit agreement on the project’s outcome that is aligned with the vision of the product/service. The amount of clarity in this stage has the ability to make or break the project.
The clarity of the outcome comes as we start building a complete project statement. As an output of this stage, a project statement becomes the single source of truth and a reflection of the initial understanding by the team as a whole. Major elements of the statement must be frozen at this stage before moving to the next stage.
The top decision maker/leader of this project is the best person to confirm the project statement and its vision (a standard project statement template for your reference)
It would not hurt to rearticulate various parts of a project statement at a later stage if needed, but any deviation in the core vision must be considered as a new project.
Milestone 2: The strategy agreement between all the core departments
Milestone two is to freeze the strategic approach between the leaders and the team. This helps the team to create broader guardrails to stay focussed on finding the right solution toward the expected outcome.
Depending on the information gathered and the wisdom that each of the team members brings to the table can create different strategies(hypotheses) to reach the same outcome. A clear understanding of the limitations and leverages of the team/organisation plays a crucial role in forming the strategies.
Whatever the final approach/strategy the leader decides to try, eventually it must be agreed upon by all the team members before moving to the next stage(even if no complete alignment, a willingness to trust the leader is important).
There can be multiple promising strategies from different viewpoints, but not all members need necessarily come to a full alignment on the selected strategy.
The leader of the project must take up complete accountability for choosing the final strategy from many potential ones. Any callout from the team members can be captured for later retrospection if the selected strategy fails.
The final strategy can be then updated in the project statement for records.
Milestones 3 and 4: The review of interface designs iterations & hand-off of the final
Milestones 3 and 4 comes within the 3rd stage of a project life cycle and the objective is to seek alignment on the way the problem is solved. This stage marks the beginning of a lot of core tactical interventions toward building the actual touchpoints of the product with its users.
The majority of the typical design process that designers talk about happens here during this stage and the design processes can vary from team to team. Irrespective of the design process, the idea is to propose a potential solution and bring the necessary alignment with the other internal stakeholders as the 3rd milestone.
It is important to have this alignment before designers start investing too much time and effort on the tactical front. Important stakeholders here can be Product, Business and Technology leaders who are accountable for the viability and feasibility of the proposed design solution.
During this milestone 3, the designers must seek approval from the stakeholders through detailed product flow walk-throughs, elements of interaction, visual design mocks and communication nuances to build the whole story convincing enough for the suggested solution.
Once the primary internal stakeholders(usually from the Product/ Business) approved the proposed solution, it must be considered locked before moving to the interface production stage.
During this time the design team will work towards covering all the edge use cases beyond the usual design production rituals like error states, empty states, platform adaptations, style guides and systems alignment, etc. This will be followed by an internal review by a lead designer for ensuring the quality of the output; the 4th Milestone.
The objective of the 4the milestone is to prepare the specification sheets for the development team and conduct a formal hand-off through a detailed walkthrough of the solution and the logic. Once the hand-off is done there should not be any new changes to the screens except the ones the developer is informed about.
Post-hand-off the design team and the development team will have a collaborative phase called the Dev-support stage, where some level of negotiations can happen internally and the final calls are made by design and tech team leads. However, there should not be any major deviations from the understanding set from the Demo and Design Handoff event.
Milestone 5: Design sign-off for the release
The 5th milestone is an important one for the design team if not for anyone else. Here the sign-off is given by the design team leader to ensure the designs are intact after they are turned into codes.
The stricter the design team is about the quality audits and benchmarks, the better it is. After all, it is what the design team is going to be judged for finally and not for the designs stuck inside the design tools like Figma, Sketch, etc.
Often there are negotiations made at this stage to ensure the release dates are not shifted. But a strong design leader knows how much is too low to not let it pass this gate of design quality check.
Milestone 6: Retrospection and learning
The 6th milestone is the most important one for the individual designers for their personal growth as designers and is often underplayed.
Product design is an iterative journey based on hypotheses and moving towards an ideal version. If one truly cares about his/her progress as a designer, they cannot ignore this milestone as this is what helps them understand how well they are doing at their job.
Conclusion:
If there is one takeaway from this article, it is the following.
It is better not to start with tactics unless the strategy is clear and frozen, and better not to hurry into strategy until the team has a solid vision with no greys tones to it. The model is built for agile teams that care for optimising time, effort and cost to a great extent.
This is not going to make you an outcome-delivering machine overnight. But it will solve the design operations problem when managing and scaling design teams. The quality of the output is still dependent on the individual team members.
Cheers,
Dhaneesh Jameson | LinkedIn | Twitter
(Product Design Leader, Filmmaker)
(Numerous discussions and debates with many of my peers in design, and leaders from other departments over the last few years have helped me shape my thoughts for this article. A special mention to ArunKumar for his direct involvement in formalising this model)
