Litex

Litex is a key factor–based search engine for legal practitioners. Instead of a single keyword box, it finds reference case authorities for PSLA (pain, suffering and loss of amenity) cases through factors such as plaintiff occupation or location of injury. As a freelance UX designer, I spent three months with CEO Chloe Chan and her team from HKU Law School, helping the product find focus and simplifying an overwhelming search interface into a flow of interactive inputs with helpful feedback.

What I did

• Facilitated remote user interviews and analysis, plus stakeholder interviews
• Strategy planning and a usability audit
• Internal workshop facilitation
• Design documentation for components, layouts, logic and interactions (Figma, Whimsical)

Finding the real users

It was easy to assume every lawyer needs case search. We organised 10 remote interviews with barristers and solicitors, mapping legal research workflows down to the distribution of roles and responsibilities inside a firm. The analysis pointed somewhere specific: the target users are not the experienced barristers you see in court, but the inexperienced ones and young solicitors who haven’t yet established a proprietary database of previous PSLA work.

A Design Studio workshop and a User Centred Design Canvas session with the CEO then sorted the solution space — the team came away much less confused about which features mattered, and which sounded cool on an interface but were trivial in the big picture.

Broaden Search

Key factor search limits scope by design; that is what saves time skimming through too many results. But it can limit the scope too much: an empty results page looks bad, and even a healthy one leaves users worrying that a not-so-important factor filtered out something useful.

We designed Broaden Search, a button that removes the next potentially unimportant key factor from the current search — and indicates how many results it will add before you click. Behind it sits a key factor hierarchy, ranked with the help of our advisors and interviewees. Broaden Search was achieved at very low development and performance cost; Auto Exclusion went one step further, automatically excluding the lowest-importance factors when a combination is too unique to return any results.

Documentation two developers could build from

Two developers had 1.5 months to build the third iteration. To deliver design ideas at maximum speed, I shared mid-fi documentation in Whimsical that breaks the application into key components, presenting their variations and interactions as flow charts — down to the little things that define a search bar, like how auto-suggestions are ranked, what opens in a new tab, and how overflow text truncates. With mid-fi as the primary spec, developers started very early and liked the elaborate interaction details; high-fidelity design, mostly focused on styling, was finished in just a few days.

My engagement ended after three months, with reflections handed over for future directions — a community-tagging ecosystem, and backend upgrades like synonym matching that Broaden Search cannot do. Litex shipped as a live beta.