Accelo Sales Module

Context

Accelo is B2B SaaS that manages time and money across an organization, spread over more than a dozen modules. The mandate was to overhaul the UX and UI of the whole product and stand up a design system, with the Sales Module as the pilot everything else would inherit. The primary constraint was to refine existing features rather than add new ones.

I was the only specialized UX professional in the company. My two teammates were talented UI and graphic designers, but neither came from research. Leadership was used to directing features from its own experience, and the slower practical steps UX depends on, like interviews and validation, weren't yet part of how decisions got made.

That set the real problem underneath the pilot. I couldn't do research-driven design in an org that didn't yet value research. The design work depended on evidence no one was collecting, so the first job was to build the practice that would produce it.

Act 1: building the research practice

I established Accelo's first UX research process on my own, so it was lean.

I started with a feature inventory of the existing product and kept it current throughout. From there I ran discovery interviews that fed personas and empathy maps I shared with product and leadership. I pulled real click-rate data on how users moved through the legacy app, ran asynchronous card sorting to understand how people expected features to be grouped, and used focus groups to validate wireframes before they went further.

A large part of the job was sanity-checking the solutions product and the POs proposed, and flagging where their assumptions were at odds with what the research showed. I did this without dev input at that stage, as the goal was to settle the direction before it cost engineering time.

Even the plumbing was mine. I established interview invitations templates, templates for presenting findings so the practice stayed consistent, and recruited users to talk to.

As a budding researcher I struggled to juggle it all, and it took about a year to get real traction. My teammates came around first and improved their own workflows. Leadership was the harder sell, so I brought the practice to more people. I ran design thinking workshops with developers, product, sales and the UX team, and trained non-UX staff to run their own user interviews, so the evidence didn't depend on me alone. The payoff was that the value of research started to permeate the org. Leadership eventually put two new team members on interview and research duty, which gave me room to focus on other aspects of the research and design.

Act 2: where research paid off, and where it didn't

Early designs had to do two things at once. It had to refine one module and establish the patterns the entire future redesign of the other modules would inherit. Designing for modules I couldn't yet audit in depth was the hardest part.

The answer was a two-part framework. An "Anchor" sits at the top of every module, carrying the common controls and the highest-priority data, with an expandable Info Bar for detail on demand. Below it is a Tabs section, where the day-to-day work happens. The split gave every future module a predictable backbone while leaving room for what each one specifically needed.

The team's visual direction was a clinical, low-color UI meant to reduce cognitive load. It tested well throughout the usability sessions. Then it failed in the closed beta. In real daily use the data density was too low, so people scrolled and searched more than they should have, and the information hierarchy was too weak to lean on. The prototypes had caught a lot, but this was the kind of problem that only becomes apparent in real world, varied workflows.

That's the call I'd defend from this project. The clinical UI passed every usability session, so the density and hierarchy failure only surfaced once real work ran through the beta, and catching it there was the harder half. The fix was a systems call. I routed the correction through the design system's tokens rather than one-off screen edits, so it propagated to every module set to inherit the pilot instead of being reworked layout by layout. The token and code execution sat with the team, but the diagnosis and the route to the fix were mine.

Outcomes

• The closed beta performed well functionally, minus a few bugs. The visual density failure was the exception, and it was caught in beta rather than after a wide release.
• The density and hierarchy problem was fixed through design-system tokens, which let the developers apply the correction quickly and consistently rather than screen by screen.
• The two-part Anchor/Tabs framework and its patterns were reused as later modules came online, which was the point of piloting with the Sales Module.
• The research practice outlived the project. Leadership assigned additional people to research duty, and it became part of how the team worked rather than something I carried alone.
• I have to be honest about the biggest gap. No adoption, task-time, or reuse metrics were captured, even though click-rate analytics existed at the time. The outcomes here are qualitative, and I'd instrument this differently now.

Reflection

Prototypes catch a lot, and they missed the thing that mattered most. The clinical UI passed every usability session and still failed on density once real work ran through it. What saved the project was validating in a closed beta before a wide release, which turned an expensive downstream mess into a fix I could route through tokens. I trust prototype testing less on its own now, and I build in a real-world validation step before anything ships broadly.

Involving product and leadership throughout the research also paid off in a quieter way. Handoffs were smooth and few decisions got re-litigated, because the people who could have objected had already seen the evidence.

The deeper lesson was about building the first design system under real constraints. It taught me to ask the scalable, real-world questions up front, about density, accessibility, and how a pattern holds across modules I can't see yet. Those questions are cheap when you plan for them and expensive to retrofit, both for the team and for users already settled into their tools. That habit is the seed of the future-proofing approach I use now.

---

Method: a self-run research practice built from a live feature inventory, discovery interviews feeding personas and empathy maps, real click-rate analytics on legacy user paths, asynchronous card sorting for feature hierarchy, and focus groups to validate wireframes. Design validated in usability sessions on hi-fi prototypes, then in a closed beta. The 17% figure is the vertical space the same Summary section gave back after the token pass, measured on the hi-fi; no adoption or task-time analytics were captured for this project.