Functionality
Attribute

In digital products, design innovations are new ways to solve user problems. "New" means faster and more efficient compared to the current solution. Essentially, it’s about redefining the user’s "job" (according to JTBD). Below, we’ll explore examples of job redefinition and break down the entire UX design process for innovative products.

It’s important not to confuse innovations with inventions. I’ve previously written about the difference between the two—check out my post here.

To determine what functionality to include in a product, I follow this structured sequence of steps.

The Functionality attribute—determining what features to include in a product—is developed in the early stages of product development, where uncertainty is high and direction is unclear:

Let’s break down the entire process in detail.

To define product functionality, we start with research. This can be done through live interviews or synthetic interviews. The latter is technically more complex, but with well-crafted prompts, it can generate valuable insights.

To conduct an interview, follow these steps:

One of the most critical steps in research is identifying the target audience. The process involves two stages:

We conduct in-depth interviews with these specific user roles to extract detailed insights.

For a nutrition tracking app, the segments and roles might look like this:

If a product has multiple segments and roles, a separate research process is conducted for each.

At this stage, we establish the specific user job we will research and design for. This step typically follows segment and role selection. The core job should be defined as a North Star for the entire team, serving as a reference point for both product development and interview question formulation.

For example, if we focus on amateur athletes, their jobs might include:

Each job requires a separate research study.

A structured interview framework is essential—otherwise, the conversation can become an unstructured flow of information, making analysis significantly more difficult. To structure interviews effectively, we need to understand two key points:

These focus areas form the foundation of the interview structure.

Every user task follows a linear process, regardless of its complexity or specifics. The fundamental sequence of actions remains the same:

Depending on the context, specifics, and complexity of the task, additional steps may be incorporated:

Our goal is not just to document user actions and tools—that would be a simple process description. Instead, we need to understand:

This ensures a successful outcome from the user’s perspective.

For each step, we develop a set of targeted questions to guide research and design decisions.

When analyzing the user experience across each step discussed above, pay attention to two types of insights:

These are insights where users explicitly express their desire for a simpler way to complete a task.

Example: All banking apps support transfers by phone number, but yours doesn’t. Users know a more convenient way exists and directly voice this gap.

These needs should be prioritized—they reflect obvious expectations based on existing standards.

These are insights where users follow familiar routines, but upon closer analysis, you discover inefficiencies. You realize that your product can help complete the same task 2x, 3x, or even 5x faster.

Example: Previously, transferring data from a phone to a computer required messengers, cloud storage, cables, etc. For most users, that was the norm.

Now, on iOS/macOS, you can simply copy a file and paste it with cmd+V—reducing the task from many steps to one.

The hardest part is figuring out a radically simpler, faster, or cheaper way to solve the task. But this is exactly where innovative ideas are born—by uncovering and acting on hidden opportunities.

A good interview script has four core parts:

Before starting the interview, it’s important to build trust with the participant. You’re a stranger, and most likely, the person has never taken part in research before. Let them know what to expect and what you're looking for.

Screening questions help ensure you're speaking with someone who has relevant experience. Without this step, you risk wasting time and collecting irrelevant data.

Ask two simple but critical questions:

If the participant isn’t a fit, end the session politely:

This approach preserves the relationship and leaves a good impression, which is useful for future sessions.

Start with easy, open-ended questions to warm up the participant and help them recall their real experience. For example:

Then move to deeper questions based on the core steps:

For additional steps like Define, Confirm, Monitor, and Modify, follow the same pattern of asking:

In general, you want to find out:

All this feeds into the User Discovery Map.

People enjoy feeling helpful. Even if the session wasn’t perfect, I always thank participants, highlight what I learned, and keep the tone warm. That goodwill often leads to stronger sessions later on.

I also ask if they’re open to future interviews. I’ve never heard “no,” and it’s a good practice. For example:

For each user role, 5 to 8 participants is usually sufficient. Research shows that most core problems and behavior patterns emerge within the first 5–6 interviews. Additional sessions help validate findings and occasionally reveal rare issues, but the rate of new insights typically drops after 8–10 interviews.

So, 5–8 respondents per role is optimal for most UX research.

AI can assist with recruitment strategy.

Use ChatGPT or DeepSeek to brainstorm potential channels. Here’s a sample prompt to generate ideas:

Once the script is ready and participants are recruited, conduct the interviews based on your structured flow, focusing on the user experience areas you've defined.

I usually record the session using audio or screen recording, so I can analyze everything later in a focused, distraction-free setting.

At this stage, the goal is to organize all gathered data into clear, actionable statements. We use the structure based on the core and additional steps discussed earlier. The process follows these steps:

During interviews, one of the first questions we asked was:

Why is the user trying to complete this task in the first place?

The answer often contains a statement that should be reframed as the Key Job Story. This becomes the North Star for the product and team. As we build solutions, we keep asking:

Do these features help the user solve this Key Job faster, easier, or cheaper?

A Key Job Story consists of three components:

Example—Nutrition Tracking App:

This Job Story serves as a guiding principle for shaping product functionality.

Clear needs are insights where users explicitly express a desire to complete a task in a simpler or more reliable way.

Let’s say we’re working on a nutrition tracking app for amateur athletes focused on muscle gain. During the goal-setting phase, we asked users what challenges they face, and received this response:

We turn this into a Desired Outcome using the following structure:

As a result, the Desired Outcome is constructed using the following formula:

Resulting Desired Outcome:

Another Example—Execution Phase:

Desired Outcome:

Another Example—Monitor Phase:

Desired Outcome:

These statements become part of the User Discovery Map, helping you prioritize what features to build and how to design functionality that truly supports the user's job.

Hidden opportunities are insights that arise when users follow familiar routines to complete a task, but through analysis, we identify that the process involves multiple manual steps that could be automated or drastically shortened.

Example 1—Prepare Phase: Calculating Caloric Needs. A user shares their detailed workflow for calculating calorie intake and macronutrients:

This is a classic hidden opportunity. The user performs manual calculations using multiple tools. Instead, our app can:

We can then define multiple Desired Outcomes:

Example 2—Execute Phase: Logging Meals and Adjusting Diet.

Desired Outcomes:

The true innovation here would be to eliminate the need to manually enter food altogether. Based on pre-filled data (BMR, TDEE, weight, body fat %, goals), the app could:

This would simplify the Execute phase dramatically—no manual logging, no searching for foods, no mental tracking of nutrient targets.

At each phase of the user’s journey—Define, Prepare, Execute, Monitor, Modify, Conclude—ask yourself:

This question is the foundation for identifying hidden opportunities and turning them into true design innovations.

To finalize this stage, you need to list all user needs and distribute them across the key steps in the job flow we’ve previously defined.

For example, when working on a nutrition tracking app for athletes focused on muscle gain, the steps might look like this:

A detailed User Discovery Map includes stages, steps, and sub-steps. This level of decomposition is sufficient to surface deep insights and uncover both clear needs and hidden opportunities.

A full breakdown of how to create this map is covered in the course “Think Like a User.”

For each step in the user journey, we place the corresponding Desired Outcomes we've identified during research.

While analyzing insights, it's also useful to prioritize needs—deciding which ones should go into the MVP and which can be addressed in later product development. Example—Execute Phase:

This is a significant and standalone need, and should likely be defined as a separate Job Story to be addressed in a future iteration of the product:

The corresponding feature might include:

To decide whether a need should be included in the core functionality or saved for future development, ask:

In the case above, the flexibility feature isn’t critical for launch, so we treat it as a future Job Story.

Competitive analysis helps identify the gap between existing product functionality on the market and the actual needs of users.

We analyze each Desired Outcome individually, evaluating how well current solutions satisfy it.

This highlights where competitors fall short—and where we can deliver better, more innovative value.

Example of a competitive analysis table follows below.

There are many effective brainstorming techniques—Brainstorming, SCAMPER, Crazy 8s, etc.—but the core idea is simple:

For each Desired Outcome, the team generates possible solutions.

Once all ideas are on the table, they are prioritized using methods like:

The goal: map each user need to a focused product solution, starting from what matters most.

At this stage, the goal is to finalize the selected solutions and convert them into testable prototypes, taking into account all scenarios and edge cases.

Follow this sequence:

Before building prototypes and testing them, you need to map out detailed interaction logic in the form of flowcharts.

This step helps you separate structural thinking from visual design, so that when it's time to draw final UI screens, your focus is purely on visual clarity—not on working through logic or edge cases. It creates mental space and improves focus at each stage.

Let’s say we’re building a barcode scanner feature for a nutrition tracking app aimed at athletes gaining muscle mass. Here's how to structure the flow using the following legend:

This structure allows you to visually map every possible scenario, including edge cases, without cluttering your design process. Each branch becomes a clean input for further design and prototyping.

Once the flowchart is complete, the next step is to translate it into a screen map, where each step in the flow is represented as a distinct screen or UI state.

Steps:

Every user action and system response from your flowchart should be mapped to a specific screen or state, ensuring no step is left unaccounted for in the UI.

Let’s say we’re working on a nutrition tracking app for athletes gaining muscle mass, and we’ve identified this Desired Outcome during the Execute phase:

To address this, we came up with a solution: а barcode scanner that uses the phone’s camera to quickly input food data.

Before diving into user flow or interface design, we first outline the user steps required to use this solution:

Next, for each step, we define a Feature Outcome—which is functionally the same as a Desired Outcome, but scoped specifically to the experience of using the solution.

Just like before, each Feature Outcome can be framed using performance metrics:

Previously, we created a screen map. Now it's time to decide which design patterns will fill those screens and bring the solution to life.

We use widely adopted, universal UI patterns for prototyping. If a needed pattern doesn't exist (e.g., a barcode scanner), we simply sketch a rough version using basic elements. Later, during UI design (Appearance Attribute), it will be turned into a proper pattern tailored for your product.

Remember: At this stage, we’re not testing usability or visual design. It doesn't matter what the screens look like—only what they do.

Your only goal here is to validate:

Visual polishing comes later. Right now, you're designing to test function, not form.