AmassAI research for life sciences, with every claim traced to its source.

A laptop on a wooden desk showing the Amass homepage: “Amass consolidates your data. Every claim cited to source.”

At a glance

Design thinking
Show the working before asking anyone to believe it. The plan comes before the run, and a source sits on every claim.
Problem
An AI research answer can draw on many sources at once, and nobody could tell by eye where a claim came from.
Approach
Each area was explored more than one way on real screens, and the version people could scan and edit won.
Outcome
Five product areas reworked, from the first question to a cited, reusable output. Our colour changes were merged into the live website.
Role
Lucie on product design, working with Emil Cronval, Head of Go-to-Market, and CEO Henrik Jensen. On the website, supporting Niels Andersen.
What we designed
  • Product strategy
  • UX/UI design
  • AI product design
  • Prototyping
  • Website design
Platforms
  • Web app
  • Website

Four UX principles the whole product follows.

  1. 01Show the plan before it runsObjective, sources and steps are visible and editable while changes are still cheap.
  2. 02Ask only what changes the planOne question at a time, with a suggested default and a way to skip.
  3. 03Keep every claim next to its sourceEvidence is there at the moment a reader doubts a statement.
  4. 04Let evidence outlive the taskSources stay in the workspace, ready for the next project.

We tried a canvas, then chose a plan people can read.

An early experiment laid research out as answer nodes on a canvas. A plan has to be scanned and edited, so it moved beside the chat, in three sections that expand on demand.

A later task: the chat on the left, and a plan on the right with output type, objective, data context and research steps.

From a question to a report the team can reuse.

A finished report goes back into the drive, ready to be a source for the next task.

  1. 01DriveFiles you upload or connect
  2. 02Data contextPrivate or team datasets
  3. 03TaskScoped to the chosen data
  4. 04QuestionIn a conversation, or in research mode with steps
  5. 05AnswerFollow-ups open a child node in the same context
  6. 06TemplatePrivate, team or premade
  7. 07OutlineDrafted from the task, or fixed with placeholders
  8. 08ReportSaved as an asset

From Report, the flow returns to Drive: Available as a source.

A scroll story: scattered evidence ends up on one shelf.

As you scroll, evidence scattered across teams and tools settles onto one shelf. Niels Andersen and the Amass team built the site; we supported them in its repository, reviewing colour and pacing on live previews.

The amass.tech home page: “Evidence you can check, not answers you have to trust.” over a dotted cream ground.

Colour marks the evidence, and everything else stays neutral.

The content spines went warm orange, the headlines neutral and the core cards cream, so colour marks the evidence and nothing else. The change was merged into the live site.

The amass.tech home page: “Evidence is scattered across teams, tools and documents.” above a shelf of orange and grey books.
01
Six source cards, from Trials to Protein databases, around the line “Reasoning drifts across data, teams, and time”.
02
“Amass consolidates your data. Every claim cited to source.” above six cards, BiomedCore to DrugCore, holding books.
03

On mobile, less content but the same order: problem first, then the answer.

Confidential

The detailed product screens are shared on request.

They show confidential client work, so Lucie sends a private link to each request she approves.

Request the full case

The calls I made

  1. D01

    One prompt, not three ways to start.

    Context
    Ask and Create split exploring from producing; Upload was added for existing files.
    Options
    • Three start modes
    • One prompt with suggestions
    Decision
    One prompt with suggestions. Type first. The system proposes the output type in the plan, where it can be changed.
    Why
    Three choices have to be read before anything can be typed. Intent is better captured in an editable plan than in a menu. Trade-off: The system has to infer intent, so it must show its guess where it can be corrected.
  2. D02

    A plan people can read, beside the chat. Not a canvas.

    Context
    An early experiment laid research out as answer nodes on a canvas.
    Options
    • Node canvas
    • Plan beside the chat
    Decision
    Plan beside the chat. Objective, data context and steps, in three sections that expand on demand.
    Why
    A canvas shows where you have been; a plan shows what is about to happen. Trust depends on the second. Trade-off: We gave up the most visually distinctive idea for the most legible one.

In hindsight

What I would do differently today.

I would put the canvas and the plan in front of scientists earlier, with questions of their own. We chose on legibility; I would like that choice to have been measured.

I would define trust signals from day one: how often people open a citation, how often they edit a plan. The next decision deserves data.

Next project

MovidoA recovery app that starts by asking what you want to get back to.

A phone on a pale ledge showing the Movido Home screen: a greeting for Daniel, the week’s activities and an appointment.