PDLC Methodology: Design Thinking for Product Development

Thanks Strelka for the illustration

Overview

In the previous article, we talked about how design thinking and similar methodologies demonstrate significant success in problem-solving, but issues arise when these methodologies are taken too literally, as 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.

A designer’s role is interdisciplinary, involving design, analytics, research, copywriting, testing, QA, and management. The quality of the product depends on each of these stages, and the designer participates in each of these stages, not just the design phase. As such, the designer’s influence is felt throughout the entire product development cycle.

To address this, the Product Design Life Cycle (PDLC) methodology is designed to consider the designer’s interaction with each stage of the product development cycle and the corresponding team member. PDLC covers not only research and testing but also the entire product development cycle, including collaboration with other team members.

Photo by Dušan veverkolog on Unsplash

Advantages of this methodology

• Improved efficiency: the methodology allows for the quick testing of design solutions, reducing the time spent on design, testing, development, and refinement.
• Reduced costs: by reducing the number of bugs in QA and production, the methodology can help reduce development costs and prevent the need for rollbacks or design refinements after release.
• Methodical and consistent process: the design process becomes methodical, consistent, and controllable, making it easier to manage and track progress.
• Better communication and collaboration: the methodology encourages designers, analysts, and engineers to communicate and collaborate effectively, ensuring that everyone is involved in the development process to the extent of their competence.
• Verified process: the team gets a verified process for solving design tasks, ensuring that everyone is working to a set of established standards and best practices.
• Facilitates onboarding: the methodology makes it easier to onboard new designers, as they always know what their next step will be and can easily understand the working process.
• Tested and proven: the methodology has been successfully implemented and tested at two large companies, demonstrating its effectiveness and viability.

When all of these conditions are met, the methodology can help improve the effectiveness of design solutions and make the entire product development cycle more efficient, cost-effective, and successful.

Photo by Klaus Steinberg on Unsplash

Features

• The methodology emphasizes the designer’s responsibility not only in the field of design but also in defining hypotheses and goals, transferring the solution to development, and assuring its success in production.
• The technical analysis is performed after the lo-fi solution is finished. This way there really is a solution to analyze, not just the abstract task description, but it’s cheap to make significant changes in the design in case of technical restrictions as it’s just a lo-fi solution.
• Each interface element is associated with a user story, and each element is designed to accomplish a specific task.
• Senior designers and Managers must approve the solution’s effectiveness before it moves to development.
• While it is possible to return to previous stages during the work, it is impossible to skip subsequent ones.
• The design reviewer’s opinion is valued immediately after the Product Manager’s, and both bear equal responsibility for the consequences.
• Design Review always takes place. Even if there is no lead designer, it’s done by other designers. If there is none, then it’s performed by business analysts or product managers.
• Each step affects the quality of the final solution. So please, try not to skip any.

This methodology places a strong emphasis on the designer’s involvement throughout the entire product development cycle and ensures that each interface element is designed to accomplish a specific task. With a focus on testing and proving the effectiveness of solutions, the methodology helps reducing the likelihood of problems arising in QA and production. The designer and other team members are held accountable for the solution’s success, with senior designers and PMs providing oversight and approval at critical points in the process.

Overall, this methodology promotes a structured and collaborative approach to product design and development.

Photo by Nico Knaack on Unsplash

PDLC: For Epics

The following methodology is described for epic tasks.

How to know if the task is epic?

Your team should have its own definition of epic tasks. As for example, you can evaluate tasks in story points (SP) and call anything bigger than 11SP (story points) an epic.

Examples of such tasks may be a new page design, payment, search, filters, dashboard, etc.

Prerequisites

• Tasks are taken only from the backlog. They don’t come from any other sources, like verbally, through your corporate messenger, or email.
• No layout is changed without a described task.
• The backlog is prioritized once per sprint/month.
• The most prioritized tasks are taken into work.
• All tasks are estimated in SP and divided into epics/non-epics.
• The necessary resources for research and testing are pre-allocated, and the tools are configured.
• The design team operates under a vertical structure, with a designated lead responsible for executing the framework.
• Consumer group representatives are an integral part of a team, actively participating in design activities.
• Tasks follow the template described below.

Task template

Required fields:

• Hypothesis: “If we make …, then we will get/increase …, because …”.
• Success criteria: goal or metrics.
• Design tasks are set only by the product team members.
• The development team has conducted a technical analysis.

Optional fields:

• Context of the task
• Possible task solution
• Deadline

Example

• Hypothesis: Restructure our app navigation, as it will make those sections easier to find.
• Success criteria: MAU for each app section and purchase conversion rate
• Context: This task was formed from an insight from our latest research, a link is provided.
• Possible solution: Instead of a burger menu, we could use a tab bar navigation.
• Technical analysis has been conducted, we have enough resources for this task.
• Deadline: May 4th

The Process

Stage 1. Preparation.

1. Receive a task that conforms to the provided template.
2. Verify if the task has not already been resolved or taken up by another designer.
3. Check the project roadmap to consider any previously planned tasks.
4. Schedule a personal discussion with the author of the task and assigned developer to clarify any questions and ensure a complete understanding of the requirements.

Stage 2. Research

1. Identify the target user categories for the proposed solution.
2. If the task involves redesigning existing functionality or similar functionality already exists in the system, we gather analytics and feedback related to them.
3. We search for existing research on the problem at hand:
   — Look for your own past researches
   — NNG.
   — Baymard University.
   — Human Interface Guidelines.
   — Material Design Guidelines 2&3.
   If we find a suitable solution that has been tested and confirmed to be successful, we move on to Stage 3.
4. If no suitable answers are found in the research, we turn to our competitors:
   — If we find a solution in three or more competitors and it fits our — –problem, we move on to Stage 3.
   — If the solution is found in only one or two competitors and fits our problem, we conduct usability testing on that solution.
5. In-depth interview with the consumer group representatives.
6. If we cannot find a suitable solution anywhere or you and your team don’t have enough confidence in the proposed solution, try gathering the necessary context by using the following methods:

• In-depth interviews with relevant end-users.
• Contextual interviews.
• Shadowing.
• User surveys.
• Usability-testing on competitor’s solution.

Stage 3. Designing the solution

Lo-Fi prototype

1. Run a brainstorming session with your team and/or other designers.
2. User Story Mapping (USM): describe user stories and prioritize the interface elements required to complete these stories. Define the functional and non-functional requirements for the task.
3. Establish core user flows.
4. If necessary, collect visual references to help guide the design.
5. Conduct technical analysis in collaboration with the developer responsible for the task to ensure feasibility. Any technical restrictions are welcome, as it’s still cheap to make changes to the solution.
6. Present the prototype to stakeholders for review and gather feedback to refine the design.

Mid-Fi prototype

1. Develop wireframes to establish the visual layout and organization of the solution.
2. Work with an editor, ChatGPT, or by yourself to craft copywriting that supports the user’s journey through the solution.
3. Validate the UX layout using the Nielsen Norman Group’s (NNG) guidelines to ensure it meets industry standards.
4. Create an animated prototype to demonstrate the user flow of your design.
5. Get feedback from a teammate designer to gain a fresh perspective and identify any areas for improvement.
6. Conduct the first round of usability testing to evaluate the user experience and identify any areas that require further refinement.
7. Make corrections to the layout based on feedback received during usability testing.
8. Conduct a technical analysis with the developer responsible for the task, but only if the solution differs significantly from the Lo-Fi prototype.

Hi-Fi prototype

1. Refine the final layout.
2. Conduct a final review of the prototype by the lead designer to ensure the design meets the established goals and is visually consistent with the product’s brand and style.
3. Present the solution to stakeholders (developers included) via a demo to ensure the design meets their expectations.

Additional features:

• For new functionality — create onboarding and pass the changes to the change log.

Stage 4. Development Handover

1. Ensure, that the task for the development is created.
2. Provide the description for the development task:
   — Describe the problem that is being solved.
   — Describe the design solution.
   — Decompose the task, creating subtasks for each functionality.
   — If there are new components and elements for the UI kit, show their –states and behavior.
   — Attach an animated prototype for the proposed solution, showing the core user flows.
   — An external designer should review the task to ensure its accuracy and completeness.
   — Arrange a meeting with the developer to clarify any questions or concerns about the task.
3. Ensure, that the task for the analytics is created. We create a task for analytics to check if the solution succeeds in reaching initial goals and metrics, and we gather data for future improvements.
4. Close the initial design task.

Stage 5. Post-Analysis

The analyst evaluates if goals/metrics were met:

• If not, the analyst creates a task for revision and provides data on analytics, anomalies, and user feedback.
• If the success criteria are met, the task is closed.

That’s all

I will post a shortened version of the PDLC for the regular tasks later, so stay tuned.

Feel free to adapt the PDLC 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.

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. It is worth noting that this methodology is continually evolving, as there is always room for improvement.