Research
When Everyone Has a Different Customer in Mind

An Ongoing Discussion on Customers
What would you do as a newcomer researcher if you were in an ongoing conversation with your team, during which everyone asserts their own understanding of the customer?
(In a UI design review)
A: I think {customer} would start to go with this questionnaire first, as it helps them to lower the barrier to using our software.B: Well, I don’t think {customer} would care so much about the onboarding; they would want to get what they want(AI-generated results) upfront without those fuzzy steps.
You wouldn’t be more familiar with it if you ever worked in a startup - people go with an assumption, rapid test, until they arrive at a flatland and see traction arising. As a researcher, I was more curious about why this conversation disentangles in this way. Here, the same term “customer” in a conversation refers to contradictory understandings, further leading to contradictory business decisions — a sign of miscommunication. Yet how would that happen in a team with stand-ups every other day, even ready to enter the development phase?
Problem probing
To understand how current perceptions of our customers have formed and how misunderstandings arise, my team and I reviewed our previous research process, which relied extensively on artificial intelligence. This process made extensive use of artificial intelligence technology. Without any specific screening criteria, the team directly recruited potential customers from users of competing products and conducted in-depth one-on-one interviews. Founders then uploaded the raw interview notes and transcribed audio recordings to ChatGPT (GPT-4o mini) to generate user insights, which the founder shared preliminarily within the team; however, at that time, we had not yet established a comprehensive user model or persona for reference.

At the same time, I conducted cross-interviews with each team member to understand the subtle differences in their perspectives. Here are my findings:
The client’s initial labels remain broad-meaning; the team finds it difficult to interpret them in depth.
Team members interpret these labels differently.
The logical relationships between labels are loose, and there is overlap; furthermore, they are not linked to the client’s purchasing decisions, usage scenarios, or product preferences, nor do they provide a comprehensive understanding (as shown in the figure above).
Methods & Data
Given the volume of existing interview data and time constraints, I decided not to recruit new participants or conduct additional interviews. Instead, I focused on data synthesis—a task previously handled by ChatGPT to generate labels for clients.
I rescreened the interview notes and recordings. Eleven participants were purposively sampled across five stakeholder groups (startup founders, artists, product managers, UX/UI designers, and independent developers; n=2–3 per group) to reflect the target user profiles aligned with the startup team's vision. The following information was collected to comprehensively reconstruct the customer profiles:
Basic demographic information: gender, age, region, occupation, income level
Behavioral data: app usage habits, frequency, pain points, and challenges
Customer needs: usage scenarios, goals, and requirements
Consumption characteristics: brand preferences, purchasing factors
Psychological characteristics: interests, lifestyle, and values
Re-design Synthesis Process
Given that the team’s understanding of users is based on labels, and that each team member’s interpretation of these labels varies, I employed a collaborative synthesis process that required all members to participate in the synthesis exercises and activities. The process includes 5 stages from the affinity group, framing, to pattern finding, narrowing down 200+ datapoints to 5 user archetypes.
Here are some highlights:
Balancing Structure and Openness in Data Grouping
To avoid falling back to the broad initial labels we established for the client, I asked that each group contain a limited number of data points (2 to 10 per group). Since the same notes can support different research findings, we are open-minded to forming as many groups as possible throughout the research process.

Structuring Insights: A Three-Element Framework and Reflexivity Practice
Another common mistake we want to avoid regarding insights is overusing attributes and descriptors, e.g., difficult, helpful, confident, etc. These terms are often subjective and fail to provide detailed information for subsequent product and business decisions, as everyone’s interpretation of them varies. Therefore, we have established a linguistic framework for insights—comprising three elements: Subject, Cognition/Decision, and Action—to clearly define user characteristics. A series of reflexivity questions is also included to guide the framing.
To have the team aware of the power of framing, I organized a brief exercise. Here we discuss how different insight might impact their actual work and decision-making.

Customer Pattern Synthesis and Visualization Strategies
To identify a comprehensive customer pattern that can inform future product and business decisions, I focused on highlighting the psychological and behavioral characteristics shared by customers. At this stage, we avoid labeling each pattern in overly simplistic terms, such as “motivation” or “purchase decision”; instead, we aim to preserve rich insights within the patterns so that the team can gain a clear understanding of customer characteristics rather than getting bogged down in the sorting process itself.
Here, we also explore common forms of customer data visualization, including empathy maps, user personas, business blueprints, prototypes, and spectra, to determine the best ways to present customer patterns.

Final Deliverables
I piloted two formats for presenting the synthesized customer patterns — User Persona and Archetype — and gathered the following feedback from the product team:
Too specific persona details (such as images, occupations, and age) may reinforce the team’s stereotypes about customers, further distracting the team from designing for customers’ psychological or behavioral patterns.
Regarding user stories, first-person narratives are more likely to spark team discussion than third-person narratives.
While labels simplify information, they help the team more efficiently absorb and reference user characteristics during regular meetings to inform decision-making.
Archetypes better illustrate user segmentation before the product has fully achieved PMF (Product-Market Fit), providing room for experimentation with different business directions later on.
Persona
Archetype


Since presenting multiple archetypes at once can be information-heavy, I created an interactive wheel visualization to make the data more accessible. The wheel displays all five archetypes along with their psychological and behavioral characteristics, allowing team members to rotate and hover for quick clues for meetings.