What Came First The Product Or The Community?
Facebook, YouTube, Twitter & the early 00–10s startups reasonably argue that the product created a medium for a community to come together & flourish; yet the most recent decade of startups would likely present evidence that a community exists prior to a sticky product. Like most rhetorical questions, the true, right, answer is likely nuance — somewhere in the middle.
Thankfully, one of the core principles of any successful product design process is to simultaneously address both of these pillars in tandem, as an effort to reduce uncertainty. Regardless of which came first, product-community fit is paramount as it’s the organic predecessor to product-market fit. Now that we have our findings from the Market Research Survey (the previous deliverable), it’s time to increase the likelihood of product-community fit by piecing together actionable portraits & stories of User Personas.
Before we go into the Why, it’s worth addressing that yes, there is a self-selected bias when the founding team decides who to send the survey to (this is one of many reasons why domain expertise & network is highly valued in founding teams). With such variance, likely most people won’t care or don’t need your product/solution. And that’s okay. The purpose of sending the survey to many is to find the few that have a deep need, not just a friendly interest, in your idea. The User Persona here aims to paint a portrait of those few possibly early evangelists.
Because you need to build a single core delightful & valuable solution for each individual user-type — you need to identify & consciously design for someone. And the only way we’ll get there is by carefully piecing together User Personas, followed by corresponding User Journey Maps, & finally pieced-together UX Wireframes. To build for each user-type, we first need to comprehensively understand them. The User Persona, this deliverable, is the bridge to our community (users/customers); it helps us understand their problems, needs & wants, in order to walk through our design solution in their shoes.
The data from the Market Research Survey isn’t actionable until the responses are properly segmented. Good ole’ market segmentation is the compass that helps know who we’re designing for, & later helps us carefully craft a well-positioned marketing message.
The goal of the User Personas is to meticulously outline user types & to accordingly write out user stories.
The template above is one we commonly use at SetDesign & the one we’ll refer to for the remainder of this section. Structurally the same every time, we like to think of the User Persona as the whole sum of three individual components:
The reasoned-out imagination necessary for these components is simple, but not easy. Therefore, we suggest approaching this deliverable in the chronological order laid out above — starting with the most objective/quantitative section & moving through into the more subjective areas afterward.
Before we dig into the specifics, it’s worth asking what’s the ideal number of User Personas? Ideally, a good rule of thumb is to commit to making a minimum of one user persona per user type. For example, a media-consuming app such as a podcast aggregator or streaming app? At least one User Persona for the single user. A marketplace app on the other hand, such as AirBNB or Uber, needs a minimum of two User Personas (one for driver/owner & one for the passenger/renter).
Next, we consider additional personas based on the data in the Market Research Survey; if there is a large signal indicating two or more distinctly different demographics, it’s likely worth creating an equal amount of User Personas.
In short, one User Persona is infinitely better than zero as you’re now designing for someone; but, ideally, resources allowing, you create one per app user type & one per distinct demographic. With that question answered, we’ll now jump into how exactly we methodically approach each component.
The demographics data from the survey should be straight-forward as it’s basic quantitative segmentation. Age, occupation, & location all translate seamlessly assuming they’re part of the survey.
The three personality adjectives are naturally much more subjective & open to interpretation & scrutiny. Ideally, the demographics provide enough data to help imagine one to three adjectives; commonly, however, this is not the case & it’s easy to struggle here. If you hit a roadblock, we suggest ironing out the “Goals” & “Frustrations” section & then doubling-back.
The bottom half of the right side maps to the product value questions from the survey. As the title, Goals & Frustrations implies, these are the driving factors for why this specific user-type can’t live without your product/solution. These should not be your assumption, but rather a synthesis of the most frequent answers for the selected segment in the survey response. To jog your memory or introduce the questions from the Market Research Survey for the first time, these questions typically look like the following:
Different user types & different user segments should have varying wants, needs, behavior & motivations. Empathy goes a long way here when trying to form an aggregated value.
It sounds counter-intuitive, but we typically leave this “About” section last; again, this is because it’s the most subjective, yet it’s also the most important component of this deliverable. The User Story in the About section is literally a narrative origin that flows into the next deliverable (User Journey Map): it’s the starting point for our interaction with the user. However, due to its subjective nature, it’s much easier to leave this component last, writing it out only once the surrounding context (demographics & goals/frustrations) is filled out.
And that’s it! With all three components now crossed-off, one User Persona is completed. Again, in a realistic scenario, it’s very likely that our app requires multiple user-types & therefore multiple User Personas — don’t be lazy, we’re now designing for someone.
The User Persona is one or more fictional representations of the idea user-types (user or customer). The template is only & always constructed from trends identified in the Market Research Survey — this includes, but is not limited to the demographics, needs, goals, & observed behavior patterns of your target audience. Depending on the user-type, some, but not all products will require multiple user personas; usually, this relationship follows a 1:1 ratio based on the user-types required for an app. Additionally, distinct demographic segments are worth considering since each different group might have varying motivations & behaviors.
The User Persona functions as a qualitative introduction to our prospective user/customer that helps us map & design upcoming deliverables through their eyes. This in-depth summary is absolutely necessary as it flows right into the first deliverable of the next module, the User Journey Map.
Each user-type needs a crystal-clear value proposition that’s mapped to a single core user-flow (often referred to as the Red Route); the best way to define this value proposition is to first create a portrait of this user-type, a User Persona. The final narrative written in the “About” section is exactly what we’ll use in the next deliverable: the User Journey Map.
Typically, the close of this deliverable & the start of the next one signals a shift in the lead designers’ responsibility. Instead of focusing on gathering market research, the focus is now on mapping out a solution — we’re moving past the research phase & into the mapping phase.
This follow up shifts the focus from creating an internal guide for all stakeholders, to now combing through potential user markets to clearly identify prospective users & their needs.
Everyone has a business idea- yet very few people ever go through with the process & crate something tangible. Where do you start if you have no technical expertise? How can show your value to an engineering partner?
Launching a product is the equivalent of testing a hypothesis (or a string of them). To do this successfully as a team, it’s imperative that everyone first agrees on said hypothesis (business model) as well as the structure of the experiment (product design).