Case study
Litex
Legal search engine

- Role
- UX designer (freelance)
- Duration
- 3 months
- User interviews
- 10+
- Key factors
- 20+
- Strategy: Identified target users & competitive advantages
- Search flow simplified with clear hierarchies for 20+ key factors
- Broaden Search at very low development & performance costs, then Auto Exclusion
- Component-based mid-fi documentation for 2 developers with just 1.5 months
- High-fi design finished in just a few days
I worked with Chloe Chan, an entrepreneur from HKU Law School, and her team as a freelance UX designer for 3 months. I helped Litex find product focus, and simplified an overwhelming search interface into a flow of interactive inputs with helpful feedback.
Litex is a key factor-based search engine for legal practitioners to find reference case authorities for PSLA (pain, suffering and loss of amenity) cases. Most search engines in the legal space are keyword-based, a single search bar like Google. The idea of using key factors is to make the process more contextual and controllable by the user: selecting values under factors commonly seen in PSLA cases, such as plaintiff occupation or location of injury.

Key responsibilities
- User interviews (remote, facilitated) & analysis
- Stakeholder interviews
- Strategy planning
- Usability audit
- Internal workshop facilitation
- Design documentation for components, layouts, logic, interactions (Figma & Whimsical)
Identifying users
Not all lawyers need to search. It was easy to assume every lawyer has a need for finding relevant cases as they prepare for client briefings, negotiation sessions or skeleton judgements for court. We organised 10 remote interviews with barristers and solicitors, and explored legal research workflows down to the distribution of roles and responsibilities in a firm. Chloe backed doing research early and often: lawyers’ time is expensive, but she went out of her way to invite a panel of interviewees of various levels of experience to talk to a guy who seemingly has no clue.
We clearly identified the target users - they’re not the experienced barristers we see in courts, but the inexperienced ones and young solicitors who haven’t established their proprietary database of previous PSLA work.
Participatory design
I held a Design Studio workshop the first time I met the whole team face-to-face, and we ran another round of user interviews to test the assumptions we made while sketching. I sat with Chloe, the CEO, to work on a User Centred Design Canvas: we prioritised the problems, motives and fears, solutions and competitive advantages. The team was much less confused. We naturally acknowledged how some features sounded cool when sketching them on an interface, but are trivial in the big picture.
Investigating emotions
The idea of key factor search is to limit the search scope, saving time skimming through too many results one by one. However, it may limit the scope too much: it looks bad when the results page is empty, and even with a good number of results, users might worry that something useful might be filtered out by a not-so-important factor they entered.
We need a way to zoom out, one step at a time. We came up with Broaden Search, a button that removes the next potentially unimportant key factor from the current search scope, with an indication of how many results it will add when clicked. To decide which key factor to suggest for removal, we set up a key factor hierarchy, ranking all of them with the help of our advisors and interviewees.

Broaden Search was achieved with very low development and performance costs, but a huge improvement to the experience of key factor search. We moved 1 step further with Auto Exclusion: to avoid combinations that are too unique to return any results, it automatically excludes factors starting from the lowest importance, saving some frustration and clicks on Broaden Search.
Component-based documentation
The devs had waited enough while we were doing research: 2 developers with just 1.5 months to build. To deliver design ideas at maximum speed, I created and shared mid-fi documentation in Whimsical. I broke down the application into key components, and presented their variations and interactions as flow charts, down to the little things that define a search bar: how auto-suggestions are ranked, what opens in a new tab or not, how overflow text truncates, and how a radio+checkbox list is expected to work.

Using mid-fi as the primary documentation, with high-fi mostly focused on styling, developers were able to start very early, and they loved the elaborate details regarding interactive elements. High-fi design was finished in just a few days.
Litex is a live beta; no updates available after Apr 2021. My time was up as a freelance consultant. Reflections for potential future directions: an ecosystem where community contribution of tags and corrections earns rewards, and backend upgrades like synonym matching that Broaden Search cannot do.