A guide for B2B product teams
I choose a UX audit or redesign based on what the team already knows.
If your team knows something is wrong with the product but cannot explain where the difficulty starts, I would investigate first. If the problem and requirements are already clear, I would scope the design work around that evidence.
I separate a visible symptom from the underlying task.
“The dashboard needs a redesign” describes a proposed solution. Before agreeing the scope, I would ask which decision the dashboard is meant to support, who makes it and what happens when they cannot find the answer.
A crowded screen might need a clearer hierarchy. It might also be showing information that belongs to different roles, or asking someone to act before the necessary data is available. Those problems lead to different design work.
I ask the team to walk through a recent example. Where did someone stop? What did they do outside the product? Which support questions or research findings help explain it?
I match the next step to the missing evidence.
| What the team knows | Where I would start |
|---|---|
| The workflow exists, but people struggle with it. | A focused UX audit to identify interface issues and assumptions that need testing. |
| The team disagrees about how people do the job. | Interviews or observation with the people using the product before specifying new screens. |
| Research identifies the problem and the intended behavior. | A design project covering the relevant workflow, states and implementation notes. |
| The same component behaves differently across screens. | A review of the design system and implementation, scoped to the repeated patterns. |
These scopes can overlap. I would agree which uncertainty to resolve first, then define the next decision the work needs to support.
I expect an audit finding to explain a specific change.
An issue list needs enough context for the team to act on it. I would document the task, the point where the interface causes difficulty and the evidence behind that assessment. I would then propose a change and explain what still needs validation.
For example, if someone loses their place after editing a record, I would look at whether their filters, selection and position are preserved when they return. “Improve the table” is too broad to define the work. The behavior after saving is something a designer and engineer can review together.
An expert review does not tell you how often an issue occurs across your users. I would use existing product evidence or user testing to investigate that, rather than attach an unsupported impact estimate.
I have worked on both sides of this decision.
At United Airlines, I worked through Safety Hub usability findings with the research team and translated them into interface requirements for an external vendor. The work had to connect a finding to something the vendor could build. Read the public Safety Hub case study.
For Neura, the founder and backend engineer already owned the financial calculations. I designed how business owners would read those insights and decide what to do next. That engagement focused on the core screens and the states between them. See the Neura product design work.
I can scope the work from a short product brief.
Describe the people using the product, the workflow that is causing concern and what your team has already learned. Share the decision you need to make and any constraints on access or timing.
I would use that conversation to decide whether a UX audit, product design project or user research is the appropriate starting point. I agree scope and fee before the work starts.
Tell me where your team is getting stuck.
I work directly with B2B software teams across Europe and North America. Send me the context and the decision you need help with, or email hello@studiogridline.com.