Reliability
Attribute

The Reliability attribute in the user-centered framework “Think Like the User” means that a product or feature doesn’t just formally exist (Functionality), but actually completes the user's task from start to finish. In other words, the product is “reliable” in fulfilling the entire Job Story—it addresses the full need, not just isolated steps.

For example, if a user wants to prevent food from burning while cooking, simply having a timer is functionality. But automatically turning off the stove when the timer ends is a reliable solution that completes the entire job. The methodology below focuses specifically on validating whether a solution fully covers the Job Story. It does not include usability testing—that's covered separately under the Usability attribute.

To properly develop the Reliability attribute, follow a series of structured steps. Overall, the validation process includes preparing and conducting Solution Interviews with users, followed by analyzing the results. Key stages:

Each step will be examined in detail below, with a focus on practical execution and success criteria.

The Reliability attribute should be evaluated after the Functionality attribute has been covered. This means that user needs must already be explored, hidden opportunities and explicit demands identified, and JTBD statements formulated—Key Job Story, Job Stories, and Desired Outcomes.

If any gaps emerge during the Reliability phase, they must be addressed before moving on (e.g., to final UI design or usability testing).

Let’s break down the entire process in detail.

Before conducting a Solution Interview, it’s crucial to determine which Desired Outcomes and scenarios are most critical to validate first. You can’t realistically test everything—so focus on what matters most.

As a result, you’ll have a shortlist of key scenarios (situations) to explore—each tied to a specific sub-step—and a set of high-priority Desired Outcomes to validate.

Next: we’ll prepare the tools needed for this validation.

To collect and analyze data from the Solution Interviews, we use a structured scoring table—the Opportunity Score Table. It helps organize user responses and see how well your concept improves each Desired Outcome.

The table includes:

For each Desired Outcome, you’ll capture:

Once filled out across interviews, this table gives you a clear view of how each outcome performs across your sample—where satisfaction improved, and where your solution still falls short.

Beforehand, pre-fill the table with all selected Desired Outcomes (each as a separate row). Leave space for the Importance and both Satisfaction ratings. Optionally add a Comments column to capture key quotes or explanations—these will help in your later analysis.

The prototype (or solution concept) is what you’ll show users during the Solution Interview to gather their feedback. It’s critical that the prototype covers the key Desired Outcomes identified during prioritization. The user must be able to try—or at least imagine—how the solution works in areas that matter most to them.

Your prototype can be:

The key requirement: the participant must clearly understand the idea behind the solution and how it addresses their Job Story. If an important outcome is missing from the prototype, the interview will surface this—users may express concern or suggest something is lacking. That’s a red flag indicating a gap in Reliability.

During the interview, you’ll present the prototype step by step, in the context of specific scenarios (sub-steps of the job). Before the interview, make sure you have a screen or description prepared for each scenario. For example, if you’re testing the scenario “Measure current body fat percentage” in a fitness app, the prototype must allow the user to input data and see the calculated body fat percentage. Otherwise, the user can’t assess the reliability of that step.

Finally, test the prototype yourself or with a colleague (run a mock interview) to ensure it works smoothly. During the actual interview, nothing should distract the participant (e.g., bugs, confusing layouts). Remember: the goal is to evaluate trust in the concept, not the user’s ability to handle an unfinished prototype.

Once the prototype is ready, it’s time to plan the Solution Interview scenario—how the session will flow, and what questions or tasks the user will go through. This type of interview is a hybrid between a user interview and a usability test, but it’s structured specifically around testing selected use scenarios.

For each prioritized scenario (sub-step), follow this structure:

Repeat the sequence for each important scenario.

Example: In a nutrition-tracking app for athletes gaining muscle mass, one scenario might be “Determining the current phase (bulking or cutting)”. First, the user rates how important it is to get that phase right, and how satisfied they are with their current method. Then, you let them try your solution (e.g. a feature that recommends a phase), and finally, they rate how well your solution performs.

Repeat this sequence for each key sub-step:

Repeat this process for each key scenario. At the end of the interview, ask a wrap-up question like:

“Overall, how would you describe the reliability of this solution? Do you feel your task is fully solved?”

Then thank the participant and end the session.

If a participant has no experience with a given sub-step (e.g. they’ve never done something you’re testing), just skip it. Leave the cells blank in your table. The Priority for that Outcome should be marked as “Not applicable.” These gaps are valid and factored into the analysis.

A Solution Interview script includes four key parts (similar to a classic in-depth interview):

Before starting, establish trust with the respondent. You're a stranger, and most participants have never taken part in such research. It's essential to explain who you are, what will happen, and what you expect from them.

Screening questions are a crucial part of preparing for a Solution Interview. They ensure data relevance and research efficiency. If a respondent lacks the required experience, the interview won’t be useful.

Ask two quick questions to assess relevance:

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 into prototype testing—show your solution, observe reactions, and go through the structured steps (importance, satisfaction before/after, etc.).

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 (you can read about segments and roles in the Functionality attribute), 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:

Your main goal during the interview is to honestly assess how much the user trusts your solution. Here are several key practices:

All of these tactics serve one purpose: to get an unfiltered, honest view of how much the user trusts your solution.

Even experienced researchers can make mistakes that reduce the value of results. Below is a checklist of common pitfalls to avoid:

Avoiding these mistakes will improve your data quality and confidence in your findings for the Reliability attribute.

Once all interviews are completed, it's time to determine whether your solution concept is truly reliable—i.e., whether it solves the user’s task without raising doubts. The analysis includes both quantitative evaluation (via the Opportunity Score table) and qualitative interpretation (comments, behavior, and user quotes).

In summary, you’ve validated Reliability if:

If these are true—proceed with confidence (e.g., to UI design and usability testing).

If not—back to the drawing board.

During analysis, it’s helpful to classify each interview case into one of three categories: complete Job Story coverage, partial coverage, or no coverage at all. This effectively reflects the user’s level of trust in the solution. Let’s break down the signs of each situation:

The solution fully addresses the user’s task, and the user is ready to trust it 100%. Signs of full coverage:

If most of your interviews fall into this category—congratulations. Your concept shows strong Reliability. Users are willing to rely on it without fear or backups. That’s the goal of this attribute.

The solution solves the problem only partially. The user sees value and may use it in some cases, but still has concerns or limited trust. Signs of partial coverage:

In short, the solution covers parts of the Job Story, but not fully enough for the user to drop their old concerns. Trust is conditional: they see some benefit but aren’t ready to rely on it completely.

For the product team, this means the solution needs refinement—either by expanding coverage, handling edge cases better, or boosting confidence (e.g., through certifications, testimonials, or guarantees) to convert these users to full trust.

This is the most critical case: the user says the solution doesn’t solve their task—or doesn’t do it reliably—so they don’t plan to use it. Signs of no coverage:

This means either (1) you targeted the wrong problem, or (2) the solution is so unreliable that users would rather deal with current frustrations than risk using it. Either way, these cases demand a serious rethink. Step back: revalidate your Job Story (Functionality stage), or rebuild key reliability mechanisms from the ground up.

During analysis, don’t just rely on scores—watch for behavioral and verbal signals. Below is a checklist of user reactions and how to interpret them, helping you decode what the user actually felt.

In summary, during analysis, create a summary for each interview:

Then aggregate the results across all interviews:

This directly informs what to prioritize for improving the product’s Reliability, showing which issues are most widespread and critical.

Reliability is one of the four pillars of UX quality (alongside Functionality, Usability, and Visual Appeal). Remove one—and the whole structure starts to wobble. That’s why it’s critical to give reliability proper attention early in the development process: make sure your solution truly addresses user needs and earns their trust.

By following the method described here—hypothesis prep, structured interviews, analysis using Opportunity Score and qualitative trust signals—you’ll get a clear view of how reliable your product feels to users, and where to improve.

Once you’ve built strong confidence in your product’s Reliability (users say things like “This is exactly what solves my problem—and I trust it”), you can move on to other areas: visual refinement, usability testing, etc.

The result? A digital product that people love—because it solves their problems fully, effectively, and pleasantly, from start to finish, with no stress or second-guessing. That’s the kind of product that actually wins.