Choosing user interface design companies: what to look for when your product is complex

Most UI design portfolios show you the same thing. Clean screens, generous spacing, a dashboard with four cards on it.

None of it tells you whether the team can handle a form with 40 fields, six of them legally required, two of them requires user education, and five of them are only applicable to certain users.

Here's how to choose a design team that can.

Have they designed for a genuinely complex domain?

Your exact industry matters less than you'd expect. What matters is whether they've worked somewhere the cost of a wrong screen is money, a missed filing, or a shipment that doesn't move.

Finance, tax, healthcare, insurance, supply chain, clinical research, logistics, energy. Different subject matter, same design conditions:

• Language you can't rewrite. Regulated terms, contractual phrasing, and field labels that legal signed off on three years ago.
• **Users who already have a mental model.** They learned the domain before they learned your product, and they'll judge the interface against the domain.
• Workflows that span days and people. Approvals, handoffs, queues, and states that sit untouched over a weekend.
• Data that arrives wrong or incomplete. Half the screens exist to reconcile something that didn't import cleanly.
• Consequences on the unhappy path. The error state is the product for a meaningful share of sessions.

Nielsen Norman Group has made the point for years that designing for domain experts is a different job from designing for the general public: experts want density and speed where novices want guidance and reassurance. A studio whose entire history is consumer onboarding has been rewarded, repeatedly, for the opposite instinct.

When regulation fixes the copy, the layout has to carry the clarity. When the layout carries the clarity, hierarchy stops being a styling decision and becomes the whole job.

Ask them to describe a domain where they had to learn the rules before they could design anything, how long it took, and who taught them. The answer tells you whether they've done it or read about it.

Can they point to a workflow they made simpler?

Ask for one workflow, start to finish, before and after. A team that distills complexity for a living can walk you through it without opening a deck.

A good answer contains most of these:

• The original step count and the new one. Real numbers, not "significantly fewer steps."
• The step they refused to remove. There's always one that looks like friction and is actually a control.
• Who taught them the workflow. A named role, a number of sessions, a sense of how long it took to stop being confused.
• What broke in testing. The first simplification usually fails somewhere specific.
• How engineering reacted. Simpler screens often cost more to build. Someone had to have that conversation.

So how do you tell distillation from deletion?

Simplification is a series of decisions about what to risk. Watch for the version where "we simplified the interface" means the complexity moved somewhere else: into a settings page, into an onboarding call, into a support macro that a human runs 40 times a week. Shifting work off the screen and onto a person is sometimes the right call. It should be a stated decision with a reason attached, not something that happened while the visuals got cleaner.

What questions do they ask about your product and users?

The first call is the audition, and it's yours to watch rather than theirs. A team that can design your product won't be able to stop itself from interrogating it, and by the end of an hour they should understand your workflow better than most of your recent hires do.

Questions that tell you they're good:

• Who's the most experienced person who uses this daily, and what else is open on their screen? Power users reveal the workflow the product was supposed to support.
• What do people do in a spreadsheet because the product can't do it? Every complex product has a shadow workflow living in Excel.
• Which screen generates the most support tickets? Support volume is usability data that already exists.
• What can't change, legally or technically? The constraints define the solution space before anyone opens Figma.
• What happens when the data is wrong? Error handling is where complex products are won or lost.
• How does someone learn this today, and who teaches them? Training material is an unflattering map of where the interface fails.

Every one of those is a question about the work rather than the software.

Questions that should give you pause when they come first:

• What are three sites whose look you like?
• How many screens is it?
• Do you have brand guidelines?

None of those are wrong. They're second-hour questions, and a studio that leads with them is scoping a visual refresh, which may not be what you need.

Who gets access to your experts?

Complex products can't be designed from your side of the table alone, so ask early what access the team needs and what they'll do if they don't get it.

A serious answer names specifics:

• Named subject matter experts, with hours attached. "Two sessions with your senior claims adjuster" beats "we'll talk to some stakeholders."
• Sessions with real users, not only the people who bought the project. Buyers and daily users describe different products.
• Read access to support tickets, sales calls, or training decks. Cheap research that doesn't cost anyone a meeting.
• A working account with realistically messy data. Demo data hides every problem worth designing around.
• An engineer present in the early process. Feasibility discovered in month three is a rework bill.

A studio that asks for none of this is planning to guess.

What should make you walk away?

Some signals are strong enough to end the conversation early.

• The portfolio is entirely marketing sites and onboarding flows. Nothing in it required understanding a domain.
• They propose a redesign before they understand the workflow. The scope was decided before you were.
• They quote a fixed price and scope on the first call. Either they're guessing, or they've decided what you're getting.
• "Simplify" appears throughout the pitch with no question about what the complexity is protecting. Some of it is load-bearing.
• No researcher or engineer on the named team. A team of visual designers will produce visual answers.
• They agree with everything you say. You're paying for judgment, and judgment sometimes sounds like disagreement.

One of these is survivable. Two or more, and you're buying a visual refresh with a discovery phase stapled to the front of it.

The bottom line

Complex products get designed well by teams who are willing to be visibly confused for a few weeks before they propose anything. Look for domain exposure where being wrong had consequences, one workflow they can show you before and after, and a first call that feels more like an interview of you than a pitch at you. Visual craft matters too, and it's the easiest of the three to verify on your own.

If you're weighing studios for a product with real workflow complexity, book a discovery call with Koi Studios and bring your hardest screen.

‍