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.

In recent years, as distributed work has become the norm, all-hands trips have become more commonplace. Even companies that have always done them now see their importance in a new light. They are expensive and demanding for everyone involved, but when they’re done well they can be incredibly impactful. Are you bringing your team together and feeling the stress of getting it right? Designing the time together takes strategic thinking, logistics planning, and the confidence to ask everyone to contribute to the event’s success.

Last week, we came together to connect, celebrate each other, and look forward to a bright future in our quarterly all-hands event we call Third Third Thursday or TTT. It was our first in-person all-hands event since May 2023. At Viget, we actively build our culture together. The responsibility doesn’t fall on just a few individuals' shoulders. Our events are successful because individuals show up, speak up, listen, and honor the limited time we have together in-person. This is evident in the chats over breakfast pastries, the all-in approach to competitions breakout sessions, and the peer talks and discussions throughout our events. This connection and camaraderie doesn’t just happen, we work hard to make it happen. 

Reflecting on last week’s event (and 7 years of other events), I want to share these five key planning tips to help you craft a successful event. 

Leverage your physical space to help achieve your event goals. This fall we had a smaller number of attendees and we wanted to encourage discussion throughout the event so we set up the room in large U shape to foster conversation. We also made the most of our exterior space, which featured a fire escape staircase, by hosting an egg drop competition. 

Over communicate, especially around when team members can expect breaks and when they can expect to be fed. As the event lead, I share my phone number multiple times ahead of and throughout the event. We also make sure to communicate in dedicated channels, including an event Slack channel for all attendees, a behind-the-scenes Slack channel for presenters only, and an event website. We share important key information like bus schedules and flight confirmations via email. In advance of the big day, we shared this slide with our team to both inform and inspire. 

Leave room for unstructured time and connection. Over the years we learned that some of the best discussions and a-ha moments come from chats over a meal or a snack during the “unplanned” parts of the event. Now we plan ahead for these, leaving ample time for unplanned, impromptu a-has. We think about airport Uber rides, charter bus rides, morning runs, evening board games, or late-night drinks and look for ways to grease the wheels of serendipity. This was especially important for us this fall since it had been so long since the last time we all gathered together. 

Look for ways to celebrate what is unique to your company. One pretty fantastic thing that comes with a quarter century in business is the community we’ve built along the way. We make a point to keep up with previous Viget employees who we proudly call our alumni. We love our alumni and enjoy recognizing their contributions to Viget. One way we do so is with annual picnics, which we host when the most current Viget employees are in town for an event. These picnics are often a great mix of reconnections and networking.

Find ways to surprise and delight. Think big and small. For example, this fall we put colored pencils and butcher block paper out during our meeting time. Our autumnal decor included blue(ish) and orange pumpkins (Viget colors!). We made a subtle callout to an internal project by serving french fries as our afternoon snack. And we surprised our team with Unreal treats for their bus rides home. The treats served as dessert and a means for us to introduce our next in-person event, our spring TTT, aka Viget25. 

Some companies advocate for all-hand retreats to be social and relaxing, but not “productive.” They tout a meeting-free event. At Viget, we see the meeting time as crucial because that is when peers share knowledge, reflect on their recent work, showcase client impact, and highlight new ideas and personal growth. Similarly, our co-founders reflect on Viget’s performance and share thoughts on the upcoming business direction. The meeting sparks genuine inspiration and creates a time for us to remember what brought us to Viget in the first place – to build world class tech in support of our clients. 

On the heels of a successful gathering, it’s time to start planning the next one. For our next event we’ll head to the Allegheny Mountains where we’ll leverage a unique and memorable venue, offer plenty of unstructured time for connection (with each other and nature), loop in alumni where appropriate, plan inspiring meeting content, enjoy many meals and treats together, and of course find ways to surprise and delight. 

Work-related travel isn't for everyone, but if you know someone who appreciates the idea of dedicated time to connect with and celebrate their peers, we’re hiring. And to all the culture champions and event planners out there, good luck with your next all-hands! 

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.