Internal Tool Usability Testing and Screen Reduction in Berlin: 2026 ROI

The verdict in three sentences

An internal tool that forces 14 screens per case costs far more in staff time than in licences or hosting. A structured approach, UX audit, then testing with 8 to 12 users, then a front-end rebuild, can target a 20 to 35 % reduction in handling time within 3 to 5 months. With 120 users, an investment of roughly 40,000 to 88,000 EUR (excl. VAT) usually pays back in under 12 months, provided you measure before and after.

Why 14 screens are so expensive

Most line-of-business applications built eight or ten years ago were designed around the data model rather than the actual task. A case handler opens the customer record, then the contract tab, then the history, then an entry form, then a confirmation dialog, and retypes the same case number three times. In Berlin, this pattern is common in insurance back offices, logistics operators, property management firms and the shared service centres that cluster around Mitte and Adlershof.

The symptoms can be measured:

• Average handling time of 18 to 25 minutes for a task that should take 12.
• Data entry error rate of 4 to 8 %, creating rework and complaints.
• Onboarding time of 3 to 4 weeks before a new hire works independently.
• Workarounds: parallel spreadsheets, sticky notes, copy and paste between tabs.

The head of operations sees the cost in workload reports, rarely as a line in a budget. A quantified audit makes it visible. In Germany there is one extra step: the works council (Betriebsrat) must usually be informed when you observe or time employees, so plan for anonymised measurement from day one.

What the programme costs in 2026

The ranges below reflect 2026 rates observed at UX agencies and consultancies in Berlin, Hamburg and Munich for a mid-sized internal tool (100 to 200 users, 10 to 20 main screens).

Total lead time is 3 to 5 months. The key lever is an architecture decision: keep the back end and existing APIs, rebuild only the presentation layer. That avoids a data migration and keeps risk low.

Gains by process

Usability tests time each process before the rebuild and again on the prototype. Here is a typical result set for a case management tool.

The biggest wins rarely come from visual polish. They come from grouping information on one screen, pre-filling known fields, a single search bar at the top and keyboard shortcuts for power users.

Running the tests properly

With 8 to 12 participants you catch roughly 85 % of major usability issues. Mix profiles: long-standing experts, recent hires, managers who approve. Each session lasts 45 to 60 minutes with 4 to 6 real scenarios drawn from that week's cases. Track time, clicks, errors and the SUS score (System Usability Scale). An ageing internal tool often scores 50 to 60 out of 100; a successful redesign targets 75 or more. Sessions can run in German or English, but the scenarios should use real German document types and field labels.

Mini case study

Jonas, head of operations at a contract management firm in Berlin, runs 120 users who each handle an average of 22 cases a day over 205 working days.

• Current time: 21 minutes per case, so 120 × 22 × 21 = 55,440 minutes a day, about 924 hours.
• After the rebuild, with a measured gain of 25 % (a cautious figure below the 30 % seen in testing): 231 hours saved per day.
• Per year: 231 × 205 = 47,355 hours.
• At a fully loaded cost of 42 EUR per hour, the theoretical value is about 1,989,000 EUR.

Jonas does not count all of it. He assumes only 10 % of that time turns into real extra capacity, absorbing growth without new hires. The value he retains drops to about 199,000 EUR a year. Against a budget of 76,000 EUR (audit 10,000, design 15,000, tests 4,500, front end 43,000, rollout 3,500), payback comes in under 5 months, even with that very conservative assumption.

FAQ

Do we need to rebuild the whole tool to save time?

No. In about 7 cases out of 10 a front-end rebuild is enough, at 32,000 to 75,000 EUR. The back end and APIs stay in place, which avoids a heavy migration. The database is only touched if testing reveals server delays above 2 seconds.

How many users should we test with?

Between 8 and 12 per round finds about 85 % of major issues. Two rounds of 8 beat a single round of 16, because the second round validates the fixes on the prototype.

How do we prove the gain to finance?

Time the processes before the rebuild over 5 to 10 days of real data, then repeat 4 to 6 weeks after the pilot rollout. A 20 % gain across 120 users already represents tens of thousands of hours a year.

What about the works council and GDPR?

Timing individual employees can count as performance monitoring, so involve the Betriebsrat early and use anonymised, aggregated metrics. In practice this adds 1 to 3 weeks to the schedule if raised at kick-off.

How long from audit to production?

Plan 3 to 5 months depending on the number of screens and how available your test users are. The audit alone takes 3 to 4 weeks and already delivers a prioritised list of quick fixes.

For managing access for these same users, read our piece on SAML, OIDC and SCIM readiness, and for continuity, our guide to taking over an orphaned web app. We also build custom web applications.

Let's scope your project. Tell us about your tool, its screens and its users: we will plan the audit, the tests and the front-end rebuild on a 3 to 5 month schedule. Detailed quote within 48 h. WhatsApp +221 77 596 93 33.