Useberry is the only product we build but within that, we’re always working on something new. Whether it’s a core product update, a standalone feature, or an integration with another tool, each sprint has its own needs and pace. Our goal is to stay user-centered through all of it.
The good news? You don’t need separate frameworks for every type of project. We use the same core approach, flexing it to fit the size and stakes of each release. Here’s how we keep testing fast, decisions collaborative, and surprises to a minimum.
Product Update Sprints (MVPs or Major Redesigns)
We kick things off with reviewing research results. Could be brief review from research finding from our senior UX researcher, clips from recent study, a few support quotes, or a key product metric that connects to the update. From that, we agree on one essentials we need to answer before shipping.
We don’t wait until the full design(or even the redesign) is formed. Instead, we prototype the riskiest part first: a critical task, a point of hesitation, or anything that would be hard to change later. We test it early with Useberry and get our actionable insights.
We review insights cross-functionally with dev, marketing, and support. With the share results function, it is very easy to share our study results for everyone to review key video recordings or review session results.
Sometimes we have to make changes to existing labels or structure and we always run a card sorting or tree testing study to we quickly check that users can still clearly understand the labels or navigate easily. If you would like to know more about how to utility the research methods the best on Useberry, you should check our article “UX Research Methods: How to Choose the Right One“
Standalone Feature Cycles
We start by writing a doc for our goals: What does success look like? What user flow are we supporting? (Maybe even, what shouldn’t break?)
We don’t test every single corner of the design. Some decisions are familiar or straightforward, and we know from experience they can be implemented with confidence. But there are always spots where we want to pause, validate, and make sure our thinking aligns with how users behave.
That’s where we focus our quick tests. A confusing entry point, a new toggle, or a setting buried in a modal can affect usability in subtle but important ways. We use preference tests or short unmoderated usability testing to gather feedback, then follow up with comments to understand the “why.”
Before locking things in, we do a dry run with the rest of the team on our own testing environment and we don’t skip the details. Elements like microcopy/help cues, and onboarding prompts may not be flashy, but they shape how confident a user feels on their first encounter. We test those too, especially when they are part of a brand-new interaction or flow.
If you would like to know more about how to get the most out of a small and quick study, you should definitely check our senior UX Researcher Harry’s article, “How To Squeeze Value From Quick UX Studies.”
Integration Projects
Our most recent integration project was with Prolific, to enhance participant recruitment options. Before anything else, we mapped out the entire journey for the new features. This helped us spot potential areas of friction early on, especially around things like permissions, and how data is handed off.
One area that needed careful thought was terminology. For example, once a submission is reviewed, users can now either “Accept & Pay” or “Ask to Return.” These labels may seem simple, but we deliberately aligned them with the exact terms used by Prolific. That way, participants who were already familiar with Prolific’s platform would instantly recognize the actions, reducing confusion and helping the experience feel seamless. We try not to reinvent the wheel just for the sake of “innovation”, keeping things intuitive and consistent is the way to avoid unexpected problems down the line.
We also made sure to familiarize ourselves with Prolific’s API early in the process. That saved us from a few surprises because let’s be honest, there are always going to be weird edge cases. We didn’t leave those to imagination. We designed small, focused tasks and used Useberry to test how users handled them.
Throughout the process, we weren’t afraid to ask for help. Prolific’s team was supportive, and we used those conversations to inform both the UX and the support content. On our side, we made sure onboarding tips, help docs, and UI copy stayed consistent and ready before release. It all pays off when the flow feels smooth from start to finish.
You don’t need a big team, just a repeatable way to learn, adjust, and move forward.
Why This Works For Us
We listen in every sprint, not just before big launches. We test work in progress, not just polished flows. We use research to inform real decisions, not to sit in documents that never get opened again.
That’s the payoff: fewer surprises, better collaboration, and a product that feels like it was designed with users, not just for them. Our process helps us move fast without losing sight of what really matters. If you’re trying to make a single change in your workflow, start by identifying the riskiest assumption in your design. Run a quick user test. Watch five people try it. If you’re seeing the same patterns, you’ve likely found your answer.
That’s how we work at Useberry. A steady, user-centered process that supports each unique product cycle. It helps us stay aligned, reduce friction, and keep improving time after time.
Design Fast, Test What Matters.
Every sprint is a chance to get things right before it’s too late. Useberry helps you validate key moments early, reduce friction, and ship with confidence.