Enterprise UX and product design services for legacy redesigns and internal tools
Which enterprise UX services a legacy redesign or a messy internal tool needs, in what order they run, and what evidence to ask an agency for at each step.
An internal tool that has grown for ten years rarely fails in one place. The support team keeps a spreadsheet open beside the case console. The finance dashboard shows yesterday’s numbers, so analysts export to Excel before every meeting. An admin screen built for a dozen people now serves hundreds. When a company asks which agencies specialize in enterprise dashboards and internal tool UX, the useful answer depends on which services the work needs.
Our comparison of agencies for enterprise dashboards and internal tools reads their published cases side by side. This guide covers the step before that shortlist: which enterprise UX and product design services a legacy redesign needs, in what order, and what evidence to ask for at each one.
How does UX scale for a large product redesign?
At Fortune 500 scale, a redesign reaches many roles, regions and systems at once, and the old product has to keep working while the new one arrives. What matters is whether an agency can plan the work in slices, tie each slice to a business goal, and hand each one to your engineers without breaking the rest. Our shortlist of enterprise product design agencies for Fortune 500 work sets out the public evidence.
Keep the old product working while the new one arrives
Continuity is the hardest part of legacy modernization. People carry years of habits into the old screens: keyboard paths, saved filters, the field they check before approving anything. Martin Fowler writes that a like-for-like replacement of a serious system usually goes badly, partly because “often it’s hard to figure out the details of existing behavior.” His Strangler Fig approach moves behavior to the new system piece by piece while old and new run side by side.
For design, that approach needs services a visual proposal rarely lists: research into what the old system actually does, workarounds included, a plan for which workflow moves first, and transitional design, so someone who switches between old and new screens during the move still finds the same names, statuses and records.
Tie each slice to a business goal
In a Designlab session called Enterprise UX Making a Difference from the Inside, Joel Miller, a director of UX in biopharma, describes enterprise UX as “balancing user needs and business goals.” Agree the measure for each slice before design starts: time to close a case, corrections to a monthly report, permission requests sent to IT. A slice is done when its measure moves, or when the team understands why it didn’t.
What about a big consultancy?
Deloitte Digital describes its work as combining “strategy, creativity, technology and managed services.” When the part you need is product design for a set of workflows, a specialist design firm can often take that slice with a smaller team, as long as integration and change management still have an owner. Our comparison of specialist alternatives to big consultancies lists firms that publish this kind of enterprise work.
Who builds each slice is a separate decision. Humbleteam can also take on development when a project needs it.
A service map for a legacy redesign
The table is illustrative, not a standard. Mark what you need, what your team covers, and what no proposal mentions.
| Service | What it produces | Continuity risk it controls | Evidence to ask for |
|---|---|---|---|
| Workflow and workaround research | Observed tasks for each role, the side spreadsheets, the exceptions | Rebuilding a process nobody follows | Notes from watching people work |
| UX audit of the current product | Problems ranked by the tasks and measures you agreed | Redesigning the screens that look worst instead of the ones that cost most | An audit report and the decisions it led to |
| Slice plan | The first workflow to move, its users, systems and measure | One big release that changes everything at once | How they chose a first slice before |
| Transitional design | Shared names, statuses and navigation across old and new screens | People losing track of a record mid-switch | Screens designed for a period when both systems ran |
| Shared patterns and design system | Tables, filters, forms and states agreed with engineering | Each team redesigning the same table its own way | A component inventory and a named owner for changes |
| Testing with real data | Prototype rounds with realistic volumes and messy records | A design that works on tidy samples and breaks on real records | Test scripts and what changed between rounds |
| Rollout support | In-product notes for changed paths, design review of each built slice | Experienced users finding a familiar shortcut gone | How they checked built screens against the design |
How do agencies design complex enterprise systems and internal tools?
Simplifying an internal tool doesn’t mean removing what experts rely on. Nielsen Norman Group’s guidelines for complex applications recommend reducing clutter without reducing capability, for instance with staged disclosure, which shows options only when they matter to the task at hand. The same article notes that “even users of complex applications tend to plateau at mediocre performance,” so good design also teaches faster ways to do familiar work.
Balance data density with clarity
Nielsen Norman Group lists four tasks a data table should support: finding records that fit criteria, comparing data, viewing or editing a single row, and acting on records. A redesign that cuts columns to look calm can break comparison. Before an agency removes anything, ask which of the four tasks each table serves. Keep density where experts compare, and move rare settings behind staged disclosure.
Research first, then test in rounds
Dashboards and complex systems need observation more than surveys. Watch people do a real task with real data, note every time they leave the tool for a spreadsheet or a chat, and prototype the riskiest step first. Then test in short rounds with the same roles, changing one decision at a time. A strong agency can show what changed between rounds; a weak one shows a final mockup.
What experience to ask an agency to show
Which agencies suit enterprise software depends on the rows of the service map your project needs. Ask each candidate for one admin or internal-tool case, one redesign of an existing product, and the names of the people who did the work. Enterprise audits are often confidential, so ask for an anonymized report and the decisions it led to.
Humbleteam publishes this guide, so it should pass the same test. Its Logitech case lists product strategy, product design and a design system for Logi Dock Flex, including the Sync admin console where IT teams draw floor plans, set group access and decide booking policies, with settings “safe to change on a Monday morning with 800 people in the building.” The design system took 4 weeks from a blank page and shipped alongside Logi Dock Flex in 2023. That was a new product, not a legacy redesign. For existing data-heavy products, Humbleteam fully redesigned Hyperliquid’s web trading dashboard and its design system, and built a design system of about 700 components for a B2B corporate banking platform whose client is not named; both are shown on request. Its design system service opens with a kind of audit: comparing live screens with the component library to find duplicates, inconsistent states and missing patterns.
Before the first agency call
- List the roles who use the tool and the side tools each one keeps open.
- Pick the first workflow to move and the measure that will show it worked.
- Mark which rows of the service map you need and which your team covers.
- Send every candidate the same slice and ask how they would keep people working during the switch.
- Ask each one for an internal-tool case, a redesign of an existing product, and the people who did both.
