Role

UX Lead

Timeline

March - June 2026

Team

3 people

Skills

  • UI and UX design
  • Product design
  • Prototyping

When Search Sensei's CEO came to our university capstone, he had a platform with real enterprise ambition and no UI to show for it.

Our three-person team took on the full design, a public-facing AI search experience, and a developer handoff document, from a blank canvas.

Context

What is Search Sensei: think smarter search, built for organisations

Search Sensei is a knowledge-discovery platform built for organisations that need to locate, understand, and reuse information at scale. It sits at the intersection of search, AI, and agentic capabilities, designed to surface the right answer confidently, not just a list of links.

Search Sensei product overview

Problem

Search has gotten smarter. The experience hasn't kept up.

AI can now answer questions directly, but most interfaces leave users with more questions than answers. Three friction points kept surfacing across existing products:

Trust and transparency

AI gives a direct answer, but its reliability is uncertain

Query formation

Not all users know how to phrase questions effectively

Information overload

Without smart filtering, results pages becomes filled with noise

Objectives

A clear brief, with real constraints

Search Sensei needed a production-ready search experience that any website could plug in, generic enough to work across industries, sophisticated enough to handle AI responses with confidence.

Our job was to design it end-to-end and hand it off to developers in a format they could build from directly

In scopeOut of scope
Public-facing AI search experienceAdmin UI
AI modeBackend infrastructure

These were the final deliverables

Full functioning prototype
Engineering handoff document

Starting Point

Search Sensei was already live. But it wasn't enough.

Search Sensei powered NAB's existing search, but it was purely traditional, no AI involved. That's exactly the gap we were designing to close.

Search Sensei product overview

Design Process

Research first, design second

We followed a Design Thinking approach, starting with understanding the space before touching any screens. Every decision from here was grounded in what we observed, not what we assumed.

Understanding the space: before designing anything, we studied what already existed

We started by analysing three products: Google, Bing, and NAB, because they represent different ends of the search spectrum: consumer-scale AI search and a real-world example of enterprise website search. For each, we mapped out every element and interaction in FigJam, screenshotted and annotated key UI patterns, then sorted them into what worked, what didn't, and what was worth adapting.

Competitor research

What we decided to carry into our design:

Predictive search
Category tags
Filters
Cards and lists

Building the wireframes

With our research locked in, we moved into wireframing: working out layout, hierarchy, and screen flow before touching any visuals. We covered the full search journey: the opening state, predictive suggestions, the loading state, search results with AI and traditional views, and the sources and citations detail screen.

Our first attempt at the design

We moved into mid-fidelity to start making real design decisions, translating wireframe structure into something you could actually react to, with real content replacing placeholders to get a true feel for the experience

Search Sensei product overview
Search Sensei product overview

Good feedback doesn't just point at problems.. it points at better decisions.

After sharing our initial concept with our client and lecturer, four things came back consistently:

  • The AI mode toggle wasn't distinct enough, users couldn't tell it was doing anything different
  • Results felt overwhelming, too much text and information competing for attention
  • No clear visual hierarchy between AI-generated and traditional results
  • Needed NAB branding applied to ground the prototype in a real context

Final Design

Search, reimagined

Here's how the final experience comes together, screen by screen.

The default state

The first thing users see when they open search. Trending searches for those who aren't sure what to ask, recent searches and favourites in the sidebar for those who are.

Search results

Results are organised by relevance, not recency. The most useful answer surfaces first, followed by a primary card and supporting results below. Every result is tagged by category so users can orient themselves at a glance.

AI Chatbot

When a search result isn't enough, users can keep going. The chatbot lets users ask follow-up questions and dig deeper, without losing the context of where they started. A “Back to search results” link keeps them oriented the whole time.

AI vs Traditional Mode

User choose how they want to search.

The same search query, two completely different experiences. Here's what changes when you choose between:

Clean, familiar results. A primary card surfaces the most relevant content at the top, followed by supporting cards and a list of additional results below. No AI involved, just the most relevant content, clearly organised.

Information Hierarchy

Designed for relevance, not recency.

Results are ranked by relevance and rendered into four distinct levels, each designed to match how much detail that result deserves.

AI summary card

Only appears when AI mode is on. Generates a synthesised response with a confidence tag, sources, and suggested follow-up questions.

Primary card

The highest-relevance result. Full-width with an image, title, and a CTA button. Always the first thing users see when AI mode is off.

Normal card

The next tier, displayed as a three-column card row with title, description, and category tag.

Lists

Remaining results as compact rows for quick scanning.

Learnings

What this project taught me

Three things I'd carry into every project from here:

Clarity comes from conversation, not the brief

Starting from a brief alone wasn't enough. Real clarity only came after several meetings with the client

Familiar patterns exist for a reason

What we designed isn't radically different from existing search, the fundamentals are the same, just executed more intentionally

Know your tool's limits before you hit them

Figma couldn't execute every interaction I had in mind. Moving to code helped, but came with its own learning curve.