In general, product design follows a consistent process where an idea is presented (in whatever way), the idea is analyzed to determine if it's feasible, then the product is designed, followed by development, testing, and finally the product is released.
However, in reality, the process that usually takes place is cyclical, not linear. Many stages have two-way connections and influence each other. For example, in the initial phase an idea is presented and validated, then it's designed, but during the design phase, they discover unanswered questions that cause the original idea to be updated. Or they might encounter a user flow issue during development that requires changes to the design. Sometimes all these stages are gone through, and when analyzing system data and user behavior, it causes a series of updates in each of the previous stages. In most companies, many stages actually proceed in parallel. For example, while the marketing team is promoting a product that has been developed so far, developers are working on developing the next section, the design team is moving forward with designing the next feature, and the product lead is focusing on the data collected so far and the vision for the next phase of the project.
Each stage has its own more detailed steps, and rarely does a purely linear process occur. In addition to this cyclical process for each section of the product, many stages for different sections proceed almost in parallel. For example, while the marketing team is promoting a product that has been developed to date, developers are working on developing the next section, the design team is designing the next feature, and the product lead is focusing on the data collected so far and the vision for the next phase of the project.
But let's get into the details of each section:
Phase One — From an Idea to a Proposed Plan
An idea can be presented in different ways:
Sometimes a person presents an idea in general terms. For example, they might say, “I'd like an app that asks me in the evening before bed to summarize the tasks I completed during the day and plan for tomorrow.”
This is a very general idea. In this case, you first need to research the idea: Maybe such an app already exists. How are people currently solving this problem? And so on.
After that, it needs to be validated: Even if this app is built, will it add enough value to users that they'd be willing to use it?
One risk with this type of idea is that the problem initially described and from which the idea was formed might not actually be a real problem.
This type of idea is called business-driven.
The next type is based on users (customer-driven) and is more commonly used in experienced companies. In this case, the idea is shaped by a need that the customer themselves has expressed. For example, a company might have a product for booking tours and tickets, and some users in the comments section or through support might say they don't need tours but would like to find a local guide so they can see places they're interested in at their own pace and interests with a guide. This could be the idea to start a new independent product or be added as a feature to an existing product.
The next type is data-driven. This approach works better for products that already exist and from which data can be extracted. For example, data might show that 40,000 users reached the final payment stage, but only 1,000 completed their payment. Here, this data is actually sending a clear signal of an existing problem—the next step should be to examine the stages the user goes through, form a hypothesis based on that to solve this problem, and then validate it.
The final type is based on market needs. Sometimes a competing company releases a product. To stay in the competition cycle, you also need to present a similar product with higher quality. A very prominent example of this is the competition between Apple and Samsung in releasing new phones.
Finally, once an idea is formed, we move to the next question: Is this product actually worth building?
Here, we come up with a vision of what we see for the product over the next 5 years, determine what work needs to be done now, and what goals we're aiming to reach.
After these points are clarified, priorities need to be established. Ideas are very expandable and extensive, but often exceed the team's capacity at that moment. In these cases, a product lead uses certain frameworks to decide which features are now a priority.
For example, they might use the RICE framework:
Reach × Impact × Confidence
———————————————————————————
EffortOr use the MoSCoW model:
What features we:
- Must have
- Should have
- Could have
- Won't have
After that, by categorizing items, we write the product's PRD (Product Requirements Document). This includes the problem, goals, user stories, requirements, and acceptance criteria for each requirement.
After the idea has been transformed from a raw idea into something that can be precisely articulated, its scope and growth potential can be identified, and its measurement criteria are clearly defined, we move to the next phase: design.
Design Phase
In this phase, the PRD is used to identify user flows, then wireframes are created, and finally the design is completed. Most used to use Figma for the design phases, but in recent years, tools like Figma Make, Claude Design, and others have really shown their capabilities. One of Figma's serious current competitors is Framer, which is also very powerful.
After that, we enter the product development phase.
Development Phase
After the final design is completed, this output along with the PRD is handed over to the development team. The first thing done here is that the development team breaks down the work into pieces—each requirement is converted into a series of smaller, estimable tasks. Usually, a system like Jira or Linear is used to track these tasks and determine who owns each one and what stage it's in.
In this phase too, the same cyclical situation I mentioned earlier occurs. Often a designer designs a flow that looks visually beautiful but is either very difficult to implement technically or doesn't align with backend limitations. Here, a discussion emerges between the designer and developer, called design-dev handoff, and often at this point some things in the design change or an alternative solution is found.
Development is divided into two sections: frontend and backend, which proceed in parallel. In larger teams, there might even be a separate team for infrastructure or DevOps, which is responsible for preparing the servers, databases, and the entire infrastructure on which this feature will run.
An important point here is the use of version control (usually Git). Each developer works on a separate branch, and after completing their work, they send their code via a pull request to the rest of the team for review. This review is itself a layer of quality control—before code enters the main version, another person reviews the code.
After development of a feature is complete, it goes through testing. Testing itself has multiple layers: first, unit tests that the developer writes themselves to ensure each piece of code works correctly. Then integration tests check whether these pieces work together correctly. Finally, QA comes in and tests the product from a real user's perspective, looking for bugs and trying unusual scenarios that the developer might never have thought of. An example that happened to me personally (I was a UI/UX designer at my previous company but also specifically had responsibility for testing one product)—while testing a search feature, I used an Arabic keyboard instead of Persian, and here it became clear that many cities couldn't be searched because certain letters have different ASCII codes. For example, the city “کرج” might appear the same on a Persian and Arabic keyboard, but in Persian the “ک” is simple, while in Arabic it's written as “ك” and has a different ASCII code.
In many companies, before a feature is released to all users, it's first released to a small group of users, which is called a beta test or soft launch. This allows any serious problems to be identified before they affect all users. Another very common method is A/B testing, where two versions of a feature are simultaneously released to two different groups of users, and then their behavior is compared to see which version performs better.
After these stages, the product is ready for final release. This also requires coordination between several teams: the marketing team must have prepared advertising content, the support team must know what this new feature is so they can answer user questions, and the DevOps team must ensure the infrastructure is ready for this new traffic volume.
But the story doesn't end there. After release, the product lead and data team come in and begin analyzing how users interact with this new feature: What percentage of users used it? Was the problem that was supposed to be solved actually solved? Has a new problem emerged? This is where we go back to that first point again: the data that's been collected can itself become the source of a new idea, or it can cause one of the previous design decisions or even the original idea itself to be revisited.