All work

Enterprise · Data · NDA · 2026

Lexio

An enterprise glossary and data-lineage tool — a single source of truth for critical data terms across a large organization.

Role
Product Designer — owned the design end-to-end, from early concepts to stakeholder presentations
Team
Business analysts and developers; client stakeholders
Scope
Two product phases — Dictionary, then CDE Explorer
Impact
Live across the organization and in active support — new features like CDE Explorer keep being added on request.
Lexio overview: the Dictionary table of business terms with alphabetical navigation, a term detail panel with domain, subdomain and stakeholders, and a data lineage graph starting from a highlighted source node

Context

Lexio was built for a large enterprise client in 2026. The front-end framework and design system were already in place — created by my team before I joined the project — so I designed within them. The challenge was making dense, technical data clear inside an existing visual language.

Problem

Large enterprises rely on hundreds of critical data elements — terms that appear across multiple applications, systems and teams. Without shared definitions, the same term could mean different things, which led to confusion, inconsistency and wasted time — especially for teams that needed to align on data before making decisions.

  • Same term, different meanings. A term could mean different things depending on who you asked or which system you looked at.
  • No single place to look it up. There was nowhere to find a term's definition and context.
  • No visibility across systems. Nobody could see where a term was being used across the organization.

Research

Requirements came from business analysts and meetings with the client. I also ran online interviews with 6 people — as many as the client could make available. Lexio is used by everyone in the organization, but people come to it with two different questions: business users want to know what a term means, while data and application teams need to know where it's used and how it flows between systems. That split shaped the whole product.

Phase 1: Dictionary

The first step was establishing a shared foundation: a searchable enterprise dictionary where employees could look up any business term, read its definition, and understand its context — domain, subdomain, subject area, and the stakeholders responsible for it. It supports alphabetical navigation and filtering by term type.

Lexio Dictionary: search by term and description, an A–Z index, saved filters, and a table of terms grouped by letter with description, stakeholders, term type, domain, sub-domain and subject area; each row has an expand chevron, and a Submit Term button sits in the header (open full size)
Dictionary. Terms grouped A–Z, with expandable rows and a Submit Term action.

Phase 2: CDE Explorer

After launch, the client came back with a new need: where is this term actually used across our systems? CDE Explorer was built on top of the existing product — it shows one term across many of the organization's applications at once.

Key decisions

Expandable rows

Dense metadata without a cluttered table.

Problem
Every term carries a lot of context — definition, domain, subdomain, subject area and the stakeholders responsible for it.
Solution
An expandable row structure keeps the interface clean while allowing users to dive deeper when needed.

See it in the Dictionary screen in Phase 1

Two ways to explore

Two starting points for two kinds of questions.

Problem
Business users and data teams start from different questions: what does this term mean — or where is it used?
Solution
One toggle switches the starting point: search by a critical data element, or by an application or component.
CDE Explorer empty state: a toggle between CDE and Application/Component above a search field, and an illustration with the prompt: Select CDE or Application to see where it's used across the organization (open full size)
One toggle switches the starting point.
CDE Explorer searched by application: a selected system with its status and business owner, and a table of the business glossary terms it contains with dataset location and field names (open full size)
Search by Application/Component.

Data lineage graph

A clear path through large dependency trees.

Problem
For large organizations with complex data graphs, navigability was critical — users could easily get lost in large dependency trees.
Solution
An interactive graph showing how a term travels from its source through connected systems, with zoom, pan and a minimap. The source node is always highlighted, making it easy to trace data lineage at a glance.
Small data lineage graph at 100% zoom: the highlighted Source node branches to two components and then to two applications, with zoom in, zoom out and Fit controls (open full size)
The source node is always highlighted.
Large data lineage graph zoomed out to 80%: the Source node fans out into many branches of application and component nodes across four levels (open full size)
Zoomed out on a large dependency tree.

Submit a term

A contribution flow that keeps the glossary alive.

Problem
A glossary is only useful while it stays up to date — and new terms keep appearing across the organization.
Solution
A Submit Term flow lets employees add new terms, so the glossary stays alive and up to date.

See the Submit Term button in the Dictionary screen in Phase 1

Accessibility

An enterprise tool is used by everyone in the organization, so accessibility wasn't optional.

  • Color contrast — all text and UI states meet WCAG AA.
  • Readable text — clear, plain labels and comfortable text sizes in dense tables.
  • Screen reader support — tables, filters and panels are labeled and readable with a screen reader.

Outcome

Outcome

Lexio is live across the organization and in active support. Feedback from the client has been positive, and the product keeps growing — CDE Explorer started as a request after launch and is now part of the product.

What I learned

Designing for data teams means designing for precision: every label, filter and state has to mean exactly one thing — the same problem the product itself solves.

  • Moving fast with limited access to users. I had fewer users to talk to than I'd like, so I learned to get the most out of every interview, lean on business analysts, and make confident decisions quickly.
  • Finding compromises with the client. I learned to communicate better with the client — explaining the “why” behind design decisions and finding solutions that work for the business without giving up the best possible experience for users.

Details, data and names are anonymized due to NDA. Happy to walk through the full process in a call.