We use cookies to improve your experience. By continuing to use this site, you agree to our Privacy Policy.
Most teams find UX problems too late. Here’s how we test with real users before any code is written.
Georgiana Nutas
Written by
Georgiana Nutas
Building modern web applications at BluDeskSoft. We write about what we learn along the way.
We'd love to chat about your project. First consultation is always free - no strings attached.
A practical accessibility checklist for small business owners.
Most software projects follow a familiar path: someone describes an idea, the team designs screens, developers build them, and only then do real users touch the product. By that point, changing direction is expensive. A confusing flow, an unclear label, or a missing step can cost days of development and another round of revisions.
At BluDeskSoft, we try to catch those problems earlier. Before a single line of production code is written, we put clickable prototypes in front of real users and watch what happens. The goal is simple: reduce the risk of building the wrong thing.
This is not a long research phase or a 100-page report. It is a focused step that sits between discovery and development. Discovery clarifies the problem and the requirements. Testing the experience shows whether the proposed solution actually works for the people who will use it.
Changing a button label or reordering a form in Figma takes minutes. Changing the same thing after it's built, tested, and connected to a database can take days. The later you find a usability issue, the more it costs to fix.
We have seen projects where a single unclear step in a multi-step form caused users to abandon the process. The team discovered it only after launch, when support tickets started coming in. A short prototype test would have revealed the problem in the first week.
The same logic applies to internal tools and client portals. Stakeholders often approve designs because they look clean, not because they have tried to complete the actual task. Watching someone struggle with a prototype is more convincing than any presentation slide.
We do not test finished visual designs. We test the interaction.
A typical prototype is built in Figma (or a similar tool) and contains the key user flows: signing up, creating a record, completing a booking, submitting a request, or finding information. The prototype is clickable. Users can move through the steps, fill fields, and see what happens next. It does not need real data or backend logic.
We focus on the journeys that matter most for the product. If the core value of the application is “customers can submit and track a request,” that flow gets tested first. Secondary screens can wait.
Before the test, we write a short script with realistic tasks. Instead of asking “Do you like this design?”, we ask users to complete a goal:
These tasks reveal where people hesitate, where they click the wrong element, and where the language is unclear.
We usually recruit 5 users per major user type. Research from Nielsen Norman Group and others has shown that five participants uncover the majority of serious usability issues. More users are useful later, but five is enough to see the main problems early.
Sessions last 30–45 minutes and can be remote or in person. We share the prototype, give the participant the task, and ask them to think out loud. We record the session (with permission), so the team can review it later.
During the session, we watch for:
After each session, we note the issues. After all sessions, we group them by severity and frequency. A problem that appears with three out of five users is treated as high priority.
We also test with internal stakeholders. They know the business rules, but they are not the same as end users. Watching a client try to complete their own process often produces useful feedback.
The output is not a polished report. It is a short list of changes and a revised prototype.
Common findings include:
We update the prototype, retest the critical fixes if needed, and only then hand the designs to development. Developers receive both the final screens and notes explaining why we made certain decisions. This reduces later questions and keeps implementation aligned with what users actually understood.
Figma is our main prototyping tool. It is fast to update and easy to share. For more complex interactions, we sometimes use ProtoPie or a simple coded prototype, but Figma covers most cases.
We record sessions with tools such as Zoom, Microsoft Teams, or Maze for unmoderated tests. Unmoderated tests (where users complete tasks on their own and we watch the recordings) are useful when we need quick feedback or input from a larger group. Moderated sessions are better when we want to ask follow-up questions.
Recruiting users depends on the product. For a B2B tool, we ask the client for access to real customers or team members who will use the system. For consumer-facing products, we use our own network or lightweight recruiting. The key is that participants match the target users as closely as possible.
This testing step comes after the discovery phase and before development starts. In discovery, we define the problem, the users, the main workflows, and the scope. Then we design the key flows and test them. Only after we validate the prototype do we move into detailed visual design and development.
The two steps complement each other. Discovery answers “What should we build?” Testing answers “Will people be able to use it?”
Clients sometimes worry that this adds time. In practice, it usually shortens the overall project. Fewer surprises appear during development, fewer revision rounds are needed after launch, and the team spends less time explaining how the product works to users and support staff.
Not every project needs full usability testing. A simple marketing site or a small internal tool with one or two users may only need a quick review with the people who will use it. For products with complex workflows, multiple user roles, or a high cost of failure, testing is worth the investment.
If the budget is tight, we still recommend at least one round of testing on the core flow. Five users and a clickable prototype can surface the biggest issues in a few days.
Testing UX before writing code is one of the highest-leverage activities in a project. It costs a fraction of what it costs to fix the same problems later, and it gives the team confidence that the product they are about to build will actually work for its users.
If you are planning a new web application or a significant redesign and want to reduce the risk of building the wrong thing, the first step is usually a short discovery and prototype testing phase. You can see how this fits into our overall process on the services page, or reach out for a free strategy call. We are happy to walk through what a realistic testing plan would look like for your project.
BluDeskSoft-1-800x450.webp)
