How to brief a design agency for enterprise internal tools

An enterprise internal-tool design brief should define the employee workflows, technical constraints, and acceptance tests before requesting agency proposals. That gives buyers a way to compare dashboard expertise, design-system delivery, and implementation support against the same assignment.

A crowded dashboard can hide several different problems. Staff may be reconciling inconsistent records, waiting for approval, or opening another application to find a missing detail. Changing the layout will help only if the project addresses the work behind it.

What should an agency understand before redesigning internal tools?

Start the brief with a recurring task. A hypothetical operations team might need to investigate a delayed order, identify its owner, and arrange a replacement. Its software may spread those steps across a queue, an order detail page, and a separate messaging tool. Describe the handoffs and the consequences of mistakes.

Ask shortlisted agencies to explain how they would learn that workflow. Their proposal should identify which employees they need to observe, which records they need to inspect, and where engineering input is necessary. A research plan that assumes unrestricted access to staff or production data needs revision before the engagement starts.

• Name the roles that perform the task and the permissions each role has.
• Describe the starting event, the completed task, and the exceptions staff handle.
• List the systems that supply data and the delays or gaps users encounter.
• Record the evidence available today, such as support requests, observed errors, and task recordings.

For a dashboard, useful success measures might include task completion, error recovery, and how often staff must leave the application. Agree on the baseline with the people doing the work. More time spent in an internal tool is not automatically a benefit.

Humbleteam’s enterprise portfolio includes design for an internal ISS resource tool for NASA and a design system for Logitech. Those are relevant starting points for a scope discussion. Buyers should still request an example of the particular workflow complexity their own project contains, along with the agency’s role in delivering it.

If AI is part of the redesign, specify what the feature may suggest and what it may execute. An assistant that drafts an explanation needs different controls from a feature that changes an order. Include the source of the suggestion, correction behavior, and what happens when the service fails.

What belongs in the design-system and accessibility scope?

The contract should name the system outputs the product team will receive. A library of visual components is useful, but implementation also needs behavior: selection in a large table, keyboard focus after an error, and the state of a record while an update is pending.

Request a component inventory, design tokens, usage guidance, and an agreed relationship between Figma and the codebase. Confirm who implements components and who approves exceptions. Ask candidates to show the same component in design and code, then walk through a correction that reached both. The enterprise design-system agency comparison can help identify candidates to assess against that requirement.

Accessibility needs its own acceptance evidence. The W3C WCAG 2.2 reference covers requirements including keyboard access, focus behavior, labels, and error identification. Ask the agency to map relevant requirements to actual workflows and document how the implemented interface will be tested. A color-contrast review alone leaves much of a working application unchecked.

Legal scope is a separate procurement question. The European Commission’s EAA overview identifies covered product and service categories. The organization’s responsible specialists should establish the obligations that apply to its product; an enterprise label by itself does not settle that question.

The proposal should also include a first release that an existing product team can adopt. The design-system migration guide covers sequencing that rollout. Before commissioning it, agree on who maintains the system after the agency finishes.

How should buyers compare a specialist agency and a large consultancy?

Compare the actual delivery team, scope, and dependencies. A specialist team may suit a focused workflow redesign. A broader program involving organizational change or several implementation partners may need coordination that a larger consultancy can provide. Firm size alone does not prove either capability.

Ask each candidate to price the same discovery and first-release package. Include research recruitment, engineering collaboration, accessibility testing, documentation, and support after handoff. A lower design fee can become an expensive proposal if the internal team must supply work that another candidate included.

The first acceptance review should use a representative employee task in a working prototype. Staff should be able to complete it, recover from an error, and explain what the system has done. Record unresolved issues and their owners before authorizing the next release.