Why Classic Design Methodologies are Fail at Product Development
It’s because they’re not designed for product development.
Design Thinking and similar methodologies have demonstrated significant success in problem-solving. However, these methods often overlook critical steps such as requirements engineering, design handoff, and quality assurance. Neglecting these steps can result in missed requirements, unfeasible designs, untested UI, or exorbitant design & development costs, and fixing bugs may cost 30x more during the production phase compared to the early stages.
Hello everyone! My name is Amir Gimaev, I’m a Senior UI/UX Designer at MY.GAMES. In the first part of my series, I’ll share a comprehensive methodology that incorporates problem solving and covers the entire product design lifecycle with a focus on cost reduction. By adopting this approach, companies can effectively optimise their design processes, reducing costs wherever possible.
This article provides a complete description of the proposed Product Design Life Cycle methodology, which you can use and modify freely; it’s solely for educational purposes. Readers can also join its community and take part in creating the ultimate design methodology, as well as find the methodology documentation itself. Any thoughts and questions are also welcome in the comments section. It is worth noting that this methodology is continually evolving, as there is always room for improvement.
Disclaimer: This article seeks to provide valuable insights for small to medium-sized design teams that lack experience in developing effective product design processes. However, even professional design teams may find some of the ideas presented here beneficial. If your team has already mastered the art of managing the product design process, I welcome your feedback and additional tips in the comments section.
The content of this article draws on a variety of public resources, as well as my own empirical experience.
This article is the first installment in a three-part series, and this post focuses on introducing the problem, while subsequent articles will provide practical solutions to help teams overcome the challenges of product design.
Introduction
The creation of a digital product is a collaborative effort, involving multiple team members with different areas of expertise: The analyst identifies user needs and pain points, forming product hypotheses; the manager prioritizes tasks to develop the product, while the designer provides solutions to the hypotheses; the copywriter creates user communication, and the researcher tests the solution; the developer is responsible for creating the final product; the tester checks its functionality.
All of these areas impact quality, and skipping any stage can result in a lower-quality product, which may negatively impact the user’s perception of the design. Users evaluate the overall product and may perceive bad design if the text is incomprehensible, corner cases are not considered, or if the interface is slow.
To avoid this, there are two ways — the designer can take over all areas and personally implement the product, which is obviously not acceptable and will at least increase the delivery time of releases at times. Or, a separate specialist can be responsible for each area, but the designer in this case must link all areas into a cohesive whole — design of a product.
How to achieve this? Through communication. The designer should check in with the work of each specialist to make sure they are consistent and compliant with the goals of the product, and the designer should ask for their expertise whenever required.
Participation from consumer group representatives is needed because socially acceptable design is impossible without the help of its future consumers; and these consumers themselves are the best sources of information about their needs and preferences. Any notion that system users are too ignorant to be aware of their own problems is unjustified. [Design for the Real World, Victor Papanek, 1971]
PDLC promotes high-quality design work and facilitates the interaction of the designer with the entire product team, including end-users. Effective communication and collaboration across different disciplines are key to creating a successful product.
PDLC takes the principles of integrated design described in Design for the Real World by Victor Papanek (1971) and applies them to modern digital product development. However, I believe my methodology is flexible enough to be used to create a diverse range of products, from chairs to cars.
Why methodologies?
Why do design methodologies matter? According to various online sources, there are several key reasons:
- Eliminating bottlenecks
- Increasing efficiency
- Addressing errors, “wicked issues,” and deviations in the design process
- Facilitating the onboarding of new designers
- Promoting transparency in the process
- Encouraging teams to work on projects methodically and systematically
- Tracking progress made easier
- Providing approved tools and methods for solving design problems
- Advocating for the designer through the methodology
While ad-hoc processes may be suitable in some situations, building an effective work process for a product team is nearly impossible without a documented methodology.
As Michael Pearson’s character in The Gentlemen (2019) aptly stated, “If you wish to be the King of the jungle, it’s not enough to act like a king. You must be The King. And there can be no doubt. Because doubt causes chaos and one’s own demise.”
The absence of a clear process can leave designers uncertain about the next steps and whether they have missed something critical.
The problem
Below you can see a comparison of probably the most popular design methodologies. Essentially, they all describe three stages and follow the scientific method:
- Research
- Design
- Testing
So what happens when we try to apply these methodologies? Let’s investigate that by conducting a thought experiment, and I’ll also include some real-life cases.
The case
Task: Design a payment form for the assistant chat.
Methodology: Design Thinking
Steps:
- Empathize: At this stage, the design team conducts multiple user interviews to gain a deeper understanding of the users’ needs, preferences, and pain points.
- Define: After empathizing with the users, the design team collects and analyzes the data gathered during the user interviews to define the users’ key pain points and expectations regarding in-chat payment.
- Ideate: During this stage, the design team conducts a brainstorming session and generates a wide range of ideas to address user pain points and expectations.
- Prototype: After selecting the most promising idea from the ideation stage, the design team creates a prototype to visualize the proposed solution.
- Test: In the final stage, the prototype undergoes rigorous usability testing to ensure that it meets user needs and expectations, as well as to identify any further areas for improvement.
Result: a well-suited solution for in-chat payments.
Although completing the designs may seem like a significant milestone in the product design process, problems can still arise:
Problem #1: Technical feasibility. After conducting a thorough technical analysis, the developer determines that the proposed design is not feasible. The developer states that implementing the design would require a complete refactoring of the current payment method, and the team lacks the necessary resources to do so. As an alternative, the developer suggests using a deep-link to redirect the user to the payment section of the app. The design is updated to reflect this change, as shown below:
Problem #2: Design Thinking does not describe the QA process, so the designer doesn’t participate in this stage; we just ship the layouts to the development team without any documentation or meetings. The final implementation lacks correct spacings, animations, incorrect colors, long screen loading time, and even missing elements, as the QA engineer does not have expertise in comparing Figma layouts with the actual front end.
Problem #3: After a feature release, the product owner comes to the realization that the payment should have been conducted using internal currency instead of actual money, but this detail was not included in the initial design requirements. As a result, the entire design must be reworked.
While this case may seem too rare or comically exaggerated, many of my colleagues across different companies have found it relatable. If you find yourself in a similar situation, then it’s time to grab a cup of tea and read on to discover the solution.
The solution
As Fernando Vera, a character from the TV series “Mr. Robot,” once famously said, “Details!” This sentiment certainly rings true in the world of product design as every little detail can make a significant impact on the success or failure of a product.
Let’s take another look at the process structure and consider ways to improve it to prevent the problems mentioned earlier. As we focus on designing the payment feature, it becomes apparent that some critical steps were missed. To address this, I have highlighted the steps that we need to include in the design process:
- Requirements engineering
- Research
- Design
- Technical analysis
- Testing
- Design handoff
- QA
- Analysis
With these steps:
- During the requirements engineering phase, we could have known initially that the payment must use an internal currency
- During the technical analysis, we could have known that the modal window is not feasible
- During the design handoff phase, the developer would had access to documentation on the designs, resulting in fewer defects
- During the QA phase, the designer could have checked the UI design, also resulting in fewer defects
Ultimately, this approach would have led to significant cost savings for both design and development, as the cost of fixing bugs grows exponentially, and by the time of post-release, it can cost as much as 30x when compared to a case where defects are fixed early on.
Most defects end up costing more than it would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business and lost development time. — Kent Beck, Extreme Programming Explained
Does this make Design Thinking a bad methodology?
Absolutely not
Design thinking has a history extending from the 1950s and ’60s, and refers to the set of cognitive, strategic, and practical procedures used by designers in the process of designing, and to the body of knowledge that has been developed about how people reason when engaging with design problems. This is a problem-solving process, not a product development process.
These oversights do not make Design Thinking a bad methodology. In fact, Design Thinking is a powerful and effective approach to problem-solving, and one which has yielded numerous successful outcomes in various industries. The key is to identify and address any potential gaps in the process to ensure a smooth and efficient product design lifecycle.
Wasn’t this done before?
None of the public resources I found described the life cycle of digital product design in detail, step-by-step, using modern best practices, and taking into account common mistakes.
There are methodologies that come really close to doing this, but I don’t find them as detailed and full-fledged as I personally need them to be. But in any case, they helped me form my own design methodology:
The solution
The Product Design Life Cycle itself will be described in the next article! Feel free to read and adapt it to your specific needs. Additionally, I encourage you to become a part of our PDLC community to stay updated on the latest news and discussions, where you may also find the PDLC methodology.
I value your input and welcome your thoughts in the comments section. If you have any questions, please feel free to ask and I will do my best to provide you with an answer. And you may follow me for future PDLC updates and news!
Conclusion
A good product designer is the glue that binds an entire interdisciplinary team together.
A good product designer knows that design is formed throughout all of the stages of the product life cycle — and every step matters.
You are a good product designer.
Special thanks
I would like to express my gratitude to my friend Ilgiz Mustafin (MSc in SE) for reviewing this article and methodology, and for providing valuable insights and ideas.
And my thanks to Strelka for the cover image.
