Concept testing is a research method that explores how a user perceives or interacts with a new idea. It usually takes place early in a project, and involves putting ideas into the “real world” to see how users will react to them.

Not every project needs to include concept testing, but it can make your solutions more user-centered. Involving users in the design process leads to products, sites, and experiences that are more aligned with user wants and needs — and ultimately more successful.

Concept testing is most useful when exploring ideas that are novel, complex, or risky. It can also help your team:

• Generate more purposeful, user-centered ideas.
• Identify which ideas provide the greatest value to users. 
• Prioritize the most promising idea(s), saving time and money.
• Evaluate any significant changes you make along the way.

I’ll cover how we use concept testing at Viget to help our clients gain clarity and develop user-centered solutions. 

This article will be part of a three-part series focused on concept testing. First, we’ll focus on planning out your concept testing. 

Form a clear plan

A successful concept test has a well-defined plan at its foundation from the start. At Viget, we work with clients to define what you want to learn, and who you want to learn from. 

Let’s imagine that you and your team are redesigning an online food delivery platform, and you have some new concepts that you want to test to see if they resonate with users.   

Focus on what you want to learn.

Start by defining research objectives. Think of these objectives as your north stars that will guide you and your team. You’ll use these for initial alignment, and then to frame what the prototype needs to do, and what feedback you really need.

You can create a strong set of objectives by asking:

• What initially sparked the motivation to test?
• Where do you have the most uncertainty about your concept?
• What are the key things you need to know through testing?

Teams usually have a lot of questions, and feel pressure to answer all of them at once. Resist the pressure! Instead, focus on the most pressing and critical — it will allow you to dive deeper into the most important areas in a session. Otherwise, you may not have the depth you need to move forward when you finish the testing.

Let’s say you've developed new solutions that span the whole user journey of online food delivery. You could spend a whole research session asking questions that cover all that breadth, but you would get much more depth by focusing on one particular moment in the journey, like the online ordering experience.

Think about who you want to talk to (and be holistic).

If you aren’t intentional about who you test with, you can end up with feedback that may not be applicable. Ideally, you’re talking to existing customers or people who would use the website or product in the future. Look at behaviors, like whether they’ve used a competitor, or hold specific sentiments, when recruiting participants. Perhaps you’re trying to expand your audience for your new food delivery app, so you may want to talk to people who cook at home frequently as well. 

Don’t forget to think holistically. Consider every person who might interact with this solution, from beginning to end, and who might be affected by it. For your new app, you'll want to test with the diner, but your solutions may also affect the restaurant host/hostess, cooks and cashier’s workflows for example. So you may need to capture their perspectives. 

Opinions aren’t strong evidence.

You may gravitate towards seeking preferences or opinions about your concepts (i.e., “which concept is better?”). But rather than focusing on which concept users like most, it’s more important to uncover user behavior. Preference-centric concept testing won’t teach you about how someone might actually interact with this concept. 

For instance, you’ll learn much more about which new concepts for online food ordering are most beneficial to users if you ask about how they might use it in a scenario. Or even better, you actually have them interact with each one.   

Questions like the ones below will give you stronger indications of user behavior:

• When was the last time you used [the competitor]?
• How might this concept fit into your day to day?
• How would you accomplish this task with the concept?

Avoid asking questions like “Which concept is better?” or “which one do you prefer?” Instead ask why one concept has advantages or disadvantages over another for a user, or how they actually envision it in their daily life. 

Even if the focus of the test is on preference (as is the case for branding or marketing research) it’s still helpful to dive deeper into what a user feels the design is communicating to them and why that prompts a specific reaction.

These key strategies that I’ve covered should get you a jump-start for successfully planning out your first concept test.

In the next article in the series, I'll dive into prototyping.

When choosing an outsourcing partner for design and development, many decision-makers naturally start by comparing hourly rates. At first glance, it seems logical: a lower hourly rate means lower project costs, right?

The truth is, hourly rates can be a misleading metric. The actual cost of outsourcing is much more complex than the dollar amount tied to hourly rates. In this article, we’ll explore why focusing on hourly rates can obscure the true cost of a project and why it’s crucial to dig deeper when evaluating potential partners. I’ll end by suggesting a few things to focus on instead of or in addition to the hourly rate.

Efficiency vs. Hourly Rates

Imagine you have two outsourcing options for a specific task:

• Pat: A developer who charges $100/hour and takes 3 hours to complete the task. 
• Terry: A developer who charges $200/hour but only takes 2 hours to complete the same task.

Pat’s hourly rate is lower and Pat’s total cost looks cheaper. The total cost for Pat is $300, while for Terry, it's $400. But there's more at play than the hourly breakdown.

Terry may be faster because they are more skilled, experienced, or familiar with the problem. They produce a higher-quality output that might need little to no revision, while Pat may deliver work requiring additional oversight, rework, or fine-tuning.

This brings us to a crucial point: efficiency and expertise often outweigh raw hourly cost.

Hidden Costs of Oversight and Management

The cost of managing lower-cost teams can quickly add up. Inexperienced or less skilled developers often require more:

• Guidance and supervision: You or your in-house team may have to spend significant time managing or directing work, which adds hidden costs to the project.
• Rework and revisions: Less-experienced teams may not get it right the first time, and even small mistakes can snowball into major issues that need to be fixed later on.
• Communication barriers: Some outsourcing teams might not be as effective in communicating progress or roadblocks, which can slow down the entire project and lead to missed deadlines.

Each of these factors chips away at the apparent "savings" from choosing a lower hourly rate.

Quality: The Long-Term Investment

Design and development work (insourced or outsourced) is an investment, not just a cost. High-quality work may come with a higher hourly rate, but the long-term savings are substantial:

• Fewer bugs and technical debt: A more experienced development team will likely deliver better code, resulting in fewer bugs and long-term maintenance issues. A more experienced designer is more likely to think through and design for all edge cases, filling in all the gaps.
• Faster delivery: A skilled team is often more familiar with best practices, frameworks, and tools that allow them to complete tasks efficiently.
• Scalability: High-quality designers and developers think ahead and design systems that can scale with your needs, preventing costly future refactoring.

The Cost of "Cheap" Work

Sometimes, "cheap" work ends up being the most expensive in the long run. Lower-quality outsourcing might require you to:

• Hire another team to fix or rebuild the work.
• Delay product launches due to unanticipated project overruns.
• Damage customer trust by releasing subpar products riddled with bugs or poor design.

In some cases, teams that seem "affordable" may not have the expertise to foresee potential pitfalls, which means costly issues arise later in the process.

Calculating the Total Cost of Ownership

To truly compare outsourcing options, decision-makers should consider the total cost of ownership (TCO), not just the hourly rate. TCO includes:

• Efficiency: How quickly and effectively can the team complete the work?
• Oversight: How much management and guidance will the team require?
• Quality: Will the output meet your expectations, or will it need significant revisions or rework?
• Maintenance: What will it cost to maintain or scale the system after the initial work is done?

A team with a higher hourly rate but lower total costs in these areas may be the more cost-effective choice in the long run. For a more complete example:

• Pat: Your $100/hr developer completes a task in 3 hours ($300), requires 1 hour of oversight from an in-house Senior Developer ($150), and eventually needs to be refactored or rebuilt entirely ($1,000).
• Terry: Your $200/hr developer completed a task in 2 hours ($400) based on a 10-minute overview from an in-house Senior Developer ($15), and makes an above-and-beyond measurable impact on page performance (priceless).

The best long-term investment becomes more clear when you consider all the variables. 

Conclusion: Think Beyond Hourly Rates

When investing in design or development, your goal should be to maximize ROI, not minimize hourly rates. When comparing outsourcing options, focus on the bigger picture—their efficiency, quality, and the hidden costs of oversight and management. Consider how your prospective partners measure up in terms of:

• Results: can they point to clear results of their work in which they played some critical role?
• References: would previous clients choose to hire them again (indicating they are worth their cost)?
• Communication: do they respond quickly and with clarity?
• Expertise: do they provide opinions and advice or are they simply order takers?
• Relevance: is their prior experience directly relevant to your needs? 
• If not, do they have a track record for navigating novelty well?

The right team might not always be the cheapest on paper, but they’ll deliver the greatest long-term value. Outsourcing isn’t about getting work done cheaply—it’s about getting it done right, and more often than not, the old mantra “you get what you pay for” holds.

This is part two of a three-part series on how to successfully conduct concept testing with users, focused on prototyping. Check out part one (planning) to learn more.
 

Prototype your concepts

Once a well-aligned research plan has been crafted, it’s time to create a prototype (or multiple) based on your concept. There are a plethora of ways you can create prototypes that communicate your concepts to users; I’ll cover strategies that will help spark meaningful reactions and conversation.

Provide context to ground your concept

We humans as a whole are poor predictors of our own future behaviors, so it’s really important that your concept testing simulates the future experience you’re trying to test. Ideally, you want to ground your concepts, so a participant can envision it in their own day-to-day. One of the best ways to do this is by building in context, whether into the prototype itself or in the way you actually test out the concepts.

You can ground a participant in what they would actually do by: 

• Adding small contextual details into the prototype (e.g. the participant’s name or location). 
• Providing the participant with a realistic scenario to frame the prototypes
• Designing a certain scenario into the actual prototype (e.g. error messages appear in).  
• Conducting the test in the actual or simulated environment where it will be used. 

Grounding a participant can make a difference in how someone interacts with your prototype. Let’s imagine you and your team are redesigning a part of an online food delivery platform for restaurants, specifically the parts that hosts and cashiers use. When you put your concept to the test, you can ground participants by “simulating” a lunch rush atmosphere (distractions, loud noises, etc).

Build real-ish prototypes

It might sound counterintuitive but you don’t need high-fidelity prototypes for concept testing. While high-fidelity prototypes may best simulate the future experience, that level of fidelity may not be feasible for a few reasons: 

• You don’t have the time to create something at that level of detail or complexity before testing.
• You don’t have the details fleshed out yet.
• You want your users to help define these details with you. 

Low to mid-fidelity (or as I like to call “real-ish”) prototypes can still get you to the insights you need and even have some unexpected benefits. It’s easier for research participants to focus on overarching concepts when interacting with low-fidelity prototypes. Higher fidelity prototypes tend to invoke feedback hyper-focused on the details. With lower-fidelity, research participants are more likely to provide critical feedback on ideas, since they don’t seem as “final.” You can also leave out certain details in a low-fidelity concept, which allows you to brainstorm with participants.

Again, crafting context is a large part of building out an idea that starts to feel “real” enough for a user to invoke a response. Some examples of real-ish prototypes with just enough context include: 

• Setting the stage with realistic scenarios for how and when research participants would reach out to an AI chat bot in a therapy app.
• Creating initial wireframes for a ride-sharing app that research participants test out in a simulated car ride experience, to understand what info is most helpful at each moment on the ride.
• Sending research participants “updates” on their food delivery order, to learn what participants might want to know about their order’s progress. 

Be selective about which concepts to show

You may have several concepts (or variations on a single concept) that you want to prototype out, and test through research. They may all feel exciting and important, but showing too many in one session can leave a research participant with decision fatigue. Even if you need to test multiple concepts to move forward, you don’t want to show every single one you’ve come up with.

Instead, you’ll want to be selective. One way to help you decide which concepts are best to test is by mapping them out on a matrix.

Let’s imagine again you and your team have generated multiple concepts for your food delivery app that aim to tempt users to order takeout more frequently. Perhaps some concepts focus on individualized recommendations, while other concepts show social trends. First, create a matrix that has extreme aspects of the concepts on each end and place them where you think they might belong. 

Then, ask yourself a few questions: 

• Are there two concepts that are too similar to each other? 
• Is this concept playing it too safe?

These kinds of concepts may not give you useful feedback because they’re not distinct enough or they’re too neutral over all. Instead, you’ll want to select concepts that are on the edges of your extremes. Those concepts will allow you to learn much more about your users and how they might interact with your concepts in the future.

These tips will help you craft prototypes that research participants can more easily and accurately react to. 

To end this series, I’ll discuss how to prepare for the actual testing in my next article.