Context
SessionLab is a professional planning platform used by more than 150,000 facilitators to design and run workshops, with a public library of 1,000+ facilitation methods. I joined on a five-month contract as Senior Product Designer to audit the platform's information architecture, diagnose usability issues across the product, and establish the foundations for a scalable design system. The engagement was diagnostic and foundational rather than delivery-focused, with a clear handoff at the end.
The Problem
SessionLab had grown into a mature product with a loyal user base, but its structure had accumulated without a controlling logic. Navigation grouped things by how the product had been built rather than how facilitators actually think about their work. For users, this showed up as disorientation during planning, reaching familiar features by trial and error rather than expectation.
The design system was a parallel problem. Patterns had diverged across the product over time, making UI changes slow and inconsistent. Every new feature required manual reconciliation with whatever pattern existed nearby rather than drawing from a shared, trusted foundation. The team was working harder than they should have been to maintain a quality bar the product was not consistently meeting.
Research & Discovery
I started with a usage-first analysis rather than a heuristic evaluation. I mapped where drop-offs and support requests clustered in the product before running any heuristic work, because heuristic evaluations tend to produce exhaustive lists weighted toward edge cases. Usage data narrowed the aperture to where friction was actually causing real cost.
I supplemented the usage analysis with stakeholder interviews with the SessionLab team to understand their roadmap constraints and what changes they could realistically act on within and after the engagement. The scope of any recommendation had to be matched to what the team could implement, not just what was theoretically optimal.
Key Findings
- The information architecture mapped to the product's build history, not to how a facilitator moves through their planning process. Features were grouped by when they had been developed, not by when a user would need them.
- Navigation friction was a structural problem, not a labelling problem. Users were disoriented because the underlying logic was wrong. Renaming sections would not have addressed the issue.
- Design system fragmentation was causing two compounding problems simultaneously: slower iteration for the engineering team, and visual inconsistency for users. Every new component required manual reconciliation with adjacent patterns rather than drawing from a shared source of truth.
- A full component library build was not achievable within the five-month window in a form the team could maintain after handoff. The right scope was a foundation: token architecture, component inventory, documented usage conventions.
My Thinking
Where the audit started mattered. The standard move is a heuristic evaluation in isolation and produce a prioritised list of issues. I chose to start from usage data instead, mapping where friction was causing real cost before running any heuristic work. A heuristic-first approach tends to produce exhaustive lists weighted toward edge cases. Usage data narrows the focus to what actually matters.
For the IA, I chose to restructure the information architecture around the facilitator's planning workflow rather than around the product's feature categories. Incremental improvement, better labelling and grouping within the existing structure, would not have been enough: the existing structure's underlying mental model was wrong. It mapped to how the product had been built in phases, not to how a facilitator moves through their work. Incremental improvement on a wrong model produces a tidier wrong model.
On the design system, I chose to establish a component inventory and token foundation rather than beginning with a full component library build. The team had a five-month engagement window. Building a complete library would have produced something incomplete and unmaintained after handoff. The foundation, a shared token set, documented usage conventions, and a component audit with clear prioritisation, was achievable, transferable, and immediately usable.
My Contribution
I was the sole designer on this engagement. I scoped the audit framework, conducted the usage analysis and heuristic evaluation, ran stakeholder interviews to understand roadmap constraints, and delivered the IA recommendation as a navigational model with rationale. The design system work included a full component inventory, a token architecture mapped to the existing product, and written documentation of usage conventions and prioritisation for the internal team to implement.
The decisions about what to address first, how to frame the IA logic, and what to include in the token foundation were mine to make within the constraints of what the team could act on after I left.
The Outcome
The new information architecture gave the team a navigational model grounded in how facilitators plan, with clear rationale they could defend to stakeholders and use to evaluate future feature placement decisions. The design system foundation gave the internal team a starting structure they could build on without starting from scratch. The audit identified the highest-impact consistency issues in the existing UI and provided a sequenced remediation path the team could work through incrementally.
The engagement produced two deliverables the team could act on immediately and a documented direction they could continue after handoff. For a short consulting engagement on an established product, that was the right measure of success.
What's Next
The design system foundations are intended to be extended by the internal team into a full component library. The IA recommendations provide a structural logic the team can use to evaluate future feature placement as the product and its library of facilitation methods continues to grow.