How to Do Product Design? Product Design Process
1.Flow Chart
I have been in design for nearly five years, learning product development primarily through hands-on experience. Coming from a visual communication background, I gained my understanding of user experience design by working on real projects rather than studying theories. My approach is entirely practical, and I prefer to explain things in a clear and straightforward way without using overly technical terms.
When I first searched for how to approach product design and where to begin, most resources focused on tools rather than the actual process. I found little information that provided a clear, step-by-step guide. That’s why I want to share my experience and document the design process I’ve developed through real-world practice.
I often describe a flowchart as the backbone of a product, much like a skeleton—without a strong structure, the entire body cannot be supported.
Currently, I work as a Product Designer at AlleyPin, where we focus on digitalizing the healthcare industry by developing a series of medical digital services through LINE. Since our product demands are driven by market changes and require rapid iteration, we adopt an MVP (Minimum Viable Product) approach—prioritizing functionality first and refining later.
However, in the early stages of refining our design process, we often struggled with User Stories brought in by the business team, leading to time-consuming efforts with underwhelming results.
Now, before designing any new feature, I always start with a Flow Chart to understand the overall process. This ensures that all team members grasp the logical consistency of the product’s new functionalities.
How to Create a Flow Chart?
2.Functional Map
A Functional Map is like the finer bones within a product. While the Flow Chart serves as the backbone that supports the entire product, we still need these finer structures to ensure everything functions properly.
In this stage, we can clarify which fields need to be added due to new features and help frontend and backend engineers identify new data that requires system-level restructuring.
When creating a Functional Map, I break it down from the main objective into "parent functions," "sub-functions," and "information nodes." The objective is typically derived from the Flow Chart and User Story, which guide the breakdown of functions, with data filled under each sub-function node. Depending on the feature's complexity, the map may have multiple hierarchical levels.
Throughout the design process, we frequently refer back to the Functional Map to refine and integrate data into the design. This step is crucial as it provides the development team with a clear overview of the product’s functionalities.
3.Wireframe
Designers extract task flows from the Flow Chart and incorporate the correct data from the Functional Map into the Wireframe. I refer to the Wireframe as the "body" of the product.
The Wireframe stage is crucial, as it allows all project members to gain a concrete understanding of the product for the first time. Based on my experience, even after creating the Flow Chart and Functional Map, the team often still has a vague understanding of the product. Everyone may have different interpretations, but as designers, we are responsible for shaping its "body."
I prefer to directly create a High-Fidelity Prototype to better define the design layout and ensure a stronger alignment among team members on the product vision.
When creating Wireframes, I arrange them horizontally based on each feature's Flow Chart. This helps keep the team focused during demos, preventing distractions across different functionalities.
Throughout the Wireframe process, I ensure that all necessary data is included upfront, avoiding last-minute decisions at the UI stage. This approach allows us to focus entirely on content structure without being influenced by UI elements.
I once conducted a demo where all features were displayed on a single screen at once. As a result, team members struggled to focus on specific functionalities during discussions, making the meeting unproductive—a valuable lesson in presentation strategy.
What is a High-Fidelity Prototype?
4.UI
The UI design phase is the most well-known part of the process. In the early days of designing products, I often assumed that for small features, I could skip the earlier steps. However, after several experiences, I realized that every step is truly indispensable.
If steps 1 to 3 are skipped, the UI phase can easily result in a product that looks polished on the surface but lacks clear functionality and structure.
I usually refer to the UI as the "skin" of the product—this is where we start considering elements like colors, typography, and visual details, much like deciding a person's skin tone, hair color, and facial features.
In design, I use a unified Design System to ensure consistency across the company’s products. This makes the UI phase the easiest part, as most decisions have already been made.
Since we have a detailed High-Fidelity Prototype, executing the design becomes efficient—UI components can be quickly pulled from the component library and applied to the interface.
Ultimately
I believe the fastest way to grow as a Product Designer is to continuously analyze product feasibility in everyday life. Participating in hackathons also helps sharpen product-thinking skills in a short time.
Additionally, developing a habit of critically evaluating other products—both their strengths and weaknesses—can significantly improve design intuition and decision-making.
Explore more
