EBP Informatique · B2B Web & Desktop
EBP — rebuilding a data-saturated management ecosystem
An accounting, business-management and finance software vendor. A multi-platform design system consumed by several teams, and a redesign of expert interfaces run from framing to handoff.
01
Context & problem
EBP publishes accounting, business-management and finance software used daily by accounting firms and small businesses. These are not products people use for pleasure: they use them because a legal obligation requires it, several hours a day, often for years.
Two characteristics shaped every design decision.
- Inherently dense interfaces. High-volume tables, multi-criteria data entry, accounting statements. Simplifying by removing information is not an option: the information is the product.
- A multi-platform ecosystem. Web and Desktop modules, built by several teams with different cycles and technical constraints.
On the user side, expert screens that had become illegible through successive additions. On the organisational side, no shared interface language between teams — so visual and behavioural divergence widened with every sprint.
My remit
Lead the end-to-end redesign of the product ecosystem, from framing to handoff, and build in parallel the design system that would stop the divergence from happening again.
02
Research & insights
Designing for experts imposes one rule: you do not guess at their profession. The research protocol therefore combined four sources, two of them quantitative.
In-depth interviews, 60 minutes each
Contextual immersions inside accounting firms, at the real workstation
Card-sorting sessions to validate the information architecture
Recruitment: three segments, known biases excluded
Recruitment distinguished three populations with opposing needs: accounting firms (intensive use, very high literacy), small businesses with low accounting literacy (reluctant use, weak command of domain vocabulary), and churned users — the most instructive segment, and the one most often forgotten. Known biases were excluded, in particular the over-representation of volunteer power users.
18 months of support tickets as a quantitative signal
Analysing eighteen months of tickets gave what twelve interviews could not: a hierarchy of frictions by actual volume. It showed recurring blockers concentrated on a small number of high-density screens — which is where the redesign went first.
“I don't want it prettier. I want to see my entries without scrolling three times.”
What observation revealed
The immersions surfaced behaviours invisible in an interview: keyboard shortcuts learned by heart, screens split across two monitors, intermediate spreadsheets, and above all a total intolerance for any change that breaks a data-entry reflex. Any redesign had to preserve expert interaction mechanics while fixing legibility.
03
Exploration & solution
Guiding principle: densify without cluttering
The work was not about removing information but about giving it structure: strict typographic hierarchy, consistent alignment and vertical rhythm, a clean split between reading zones and entry zones, and actions grouped by real usage frequency rather than by menu logic.
Information architecture validated by card sorting
The nine card-sorting sessions produced a structure drawn from users' vocabulary rather than from the internal organisation of modules. Divergences between the firms' sorting and the small businesses' sorting were resolved with one stable navigation plus direct access, rather than two competing hierarchies.
Dense screens: the calls we made
- Tables: persistent headers, frozen priority columns, numeric alignment on tabular figures, adjustable rather than imposed density.
- Multi-criteria entry: inline validation, error messages next to the field, and strict preservation of the tab order expert users expect.
- Accounting statements: read first, act second — secondary commands moved out of the main reading flow.
A more ambitious visual redesign was considered. The immersions showed it would break data-entry reflexes built over years. We preserved the interaction mechanics and concentrated the effort on legibility and structure: the usability gain was real, the relearning cost nil.
Readout workshops
Every phase closed with a workshop bringing together Product Owners, Product Managers and engineering teams: research results, trade-offs, and direct translation into backlog items.
04
UI & design system
The design system was built in Figma to be consumed simultaneously by Web and Desktop modules, drawing on Material Design and Ant Design standards — Material for interaction foundations, Ant Design for its data patterns, which suit management interfaces particularly well.
System structure
- Design tokens aligned with front-end variables, so the mockup's vocabulary is literally the code's vocabulary.
- Component library with complete states — rest, hover, focus, active, disabled, loading, error, empty — because in management software the secondary states account for most of the screen time.
- Reusable patterns for the domain's recurring objects: data table, multi-criteria entry form, advanced filter, accounting statement.
- Documentation maintained in Figma and Notion: when to use a component, when not to, edge cases, accessibility criteria.
Governance
A design system without governance diverges within a quarter. I set up regular alignment workshops with POs, PMs and engineers, design reviews on new contributions, and UI QA on staging builds to catch the gap between mockup and actual rendering before release.
Accessibility in the foundations
WCAG and RGAA criteria were built in at component level: contrast verified across all states, click targets sized, visible focus drawn explicitly, correct table structures. Handling accessibility in the system avoids handling it again in every screen.
05
Impact & learnings
One design system consumed by several teams
Distinct user segments covered, including churned users
Of support tickets analysed as a quantitative signal
What I took away
Churned users are the best panel there is. They have nothing left to protect and describe precisely the moment the product became unbearable. No other segment gives you that.
Support is a measuring instrument. Eighteen months of tickets rank frictions by real volume — a prioritisation neither product intuition nor twelve interviews can produce on their own.
In expert interfaces, stability beats elegance. Breaking a data-entry reflex costs the user more than a visual improvement gives back. The constraint shifts: you have to improve without displacing.
What I would do differently. I would set up UI QA on staging builds from the very first component shipped rather than halfway through: several mockup-to-render gaps were caught later than they should have been.