Free checklist Book a call →
Home/ Solutions/ Design consulting and design systems

Consulting

Design consulting for teams who already have a product

You have a product and users. Something in it costs you: sign-ups that stall, screens nobody can explain, a UI that drifts with every release. We review what exists, say what to change, and build the system that holds it together.

Book a call → Get the CTO checklist

What this covers

Design consulting for teams who already have a product, end to end.

Product design review

We go through the live product screen by screen, with your analytics and support tickets open beside us. You get a written list of what is broken, what it costs you, and what to fix first.

Design system build

Colour, type, spacing, states and a component set, defined once and documented. Built in Figma and in code, so what a designer draws and what an engineer ships are the same thing.

Component library in code

The design system as real components in your stack, or as Webflow classes and symbols. Tokens, variants and states included, so a new screen is assembled rather than drawn from scratch.

Journey and flow redesign

We take one journey that matters, such as sign-up, checkout or the task your users repeat daily, and rework it end to end: screens, copy, empty states, errors and the edge cases usually left out.

Accessibility review

A pass against WCAG 2.2 AA: contrast, focus order, keyboard paths, labels and screen reader behaviour. You get the failures listed by severity, with the fix for each one written out.

Handover and design QA

We write the usage rules, review builds against the design, and sit with your engineers while the first screens go through. The system only holds if the team can use it without us.

How it runs

Plan. Build. Run.

01

A 30 minute call

You tell us what the product is, who uses it and what is going wrong. We ask what you have already tried. If design consulting is not what you need, we will say so on the call rather than sell you a project.

02

Fixed scope, timeline and price

We write down what we will review or build, what you get at the end, when it lands and what it costs. You approve that before any work starts. Nothing is billed by the hour and nothing is open-ended.

03

Review first, then build

The review comes first and is useful on its own. If a system follows, we build it against the problems the review found, in agreed stages, with something you can look at and comment on each week.

04

Handover, and we run it if you want

You get the files, the code and the rules, and they are yours to keep. If you would rather not maintain it, our we-run retainer keeps the system current as the product changes.

Why infoloop

We do not hand over and leave.

  • We build, so the design is buildableWe ship software as well as design it. What we hand over has been through the same constraints your engineers work under, so it does not fall apart at the build stage.
  • The review is written downYou get a document with findings, severity and the fix for each, not a workshop and a feeling. It stays useful after we leave, and you can hand it to whoever does the work.
  • We say what to do firstAnyone can produce a long list of problems. We order ours by what each one costs you and what it takes to fix, so you know what to do this month and what can wait.
  • We stay if you want us toMost agencies hand over and leave. Our we-run retainer covers monitoring, fixes with response targets, improvements and a monthly report, for the design system as well as the software.
  • No redesign for the sake of itIf your product works and the problem sits elsewhere, we will say so. We would rather scope a small piece of work that pays for itself than sell you a rebuild you do not need.

What you get

Every engagement includes these, in writing, before work starts.

  • A written design review with every finding ranked by severity and effort
  • Annotated screens showing what is wrong and what replaces it
  • A Figma library of tokens, components, states and variants
  • The same components in code, or as Webflow classes and symbols
  • Usage rules covering when to use each component and when not to
  • A prioritised fix list your engineers can pick up without us

Who this is for

Three situations where this is the right call.

The product grew and the UI drifted

Three years of features, four people who touched the front end, and now every screen is slightly different. Nothing is broken enough to stop for, but each new feature takes longer than the last. That is the case for a system.

Usage is fine, one step loses everybody

Traffic arrives, trials start, and one specific step in the product bleeds people. You have the analytics showing where, and no clear read on why. Reviewing that journey properly is cheaper than guessing at it.

You are hiring designers into nothing

You are about to bring designers in, or you have one and they are drowning. There is no library, no rules and no shared file. Setting the system up before they start is far quicker than untangling it afterwards.

Questions

What buyers ask us first.

How much does design consulting cost, and how is it priced?
We price each engagement as a fixed amount rather than by the hour. After a 30 minute call we write down the scope, the deliverables, the timeline and the price, and you approve all of it before any work starts. A review of an existing product is a smaller, self-contained piece of work than building a design system, and the two are priced separately, so you can take the review on its own and decide about the system afterwards. If the scope changes part way through, we re-quote rather than quietly bill more.
Do we have to rebuild the product to act on the review?
No. Most of what a design review finds can be fixed inside the product you already have: contrast, spacing, labels, ordering, error states, the wording on a button. We look for changes your engineers can make without a rewrite, and we mark clearly which findings are cheap fixes and which need real work. If we do think a rebuild is the honest answer, we will say so and explain why, but that is a conclusion we reach, not a starting position.
What happens after the design system is handed over?
It is yours: the Figma file, the code and the documentation, with no licence and no lock-in. A design system decays if nobody maintains it, so you have two options. Your team owns it, and we leave the usage rules and a handover session so they can. Or we keep it under our we-run retainer, which covers monitoring, fixes with agreed response targets, improvements, security updates and a monthly report. You can start with the first and move to the second whenever the product begins changing faster than the file does.
How long does a design review take?
It depends on how large the product is and how much of it we are asked to look at. Reviewing one journey is a much shorter piece of work than reviewing an entire application, and we agree that boundary before we start. Whatever the size, you get the timeline in writing as part of the scope, along with the date the written review lands. We would rather scope a narrow review you get quickly and can act on than a wide one that arrives after the decision has already been made.
Can you work with our existing designer or engineering team?
Yes, and that is usually the better arrangement. If you have a designer, the system belongs to them once it is built, and we work to their judgement on brand and taste. If you have engineers, we agree the component naming and structure with them early, because a system named the way the design team thinks and built the way nobody codes gets abandoned. We can work in your Figma and your repository, or hand over files you import. We are not trying to replace anyone on your team.
What if we have no user research or analytics to work from?
We can still run the review, and we will be clear about which findings are evidence and which are judgement. Inconsistent components, broken states, accessibility failures and standard usability problems can all be found by inspection alone. Anything about what users want, or why they drop off at a particular step, is a guess without data, and we will label it as one rather than dress it up as a finding. If you want that evidence first, we can set up the tracking or run a small round of sessions, scoped separately.

Related

You might also need.

Product Consulting

Scope, sequence and the number the work has to move.

See more →

Tech Consulting

Architecture and platform decisions, with the trade-offs written down.

See more →

Digital Marketing Consulting

Channel strategy and measurement, grounded in your own data.

See more →

Have a product already? Let us review it.

Book a 30 minute call. Tell us where the product hurts and we will say whether a review, a design system or neither is the right piece of work, then scope it with a fixed price before anything starts.

Book a call → Get the CTO checklist
Book a call Checklist