One AI stream, two very different readers
Bringing an AI audio-journaling feature into a health product: splitting one stream of AI data into a screen a user reads in three seconds and a clinical dashboard a professional can work from.
- Role
- Product Design, UX, Information Architecture, Design Systems
- Discipline
- UX / UI Design
- Year
- 2025
- Headline
- 2 in 1 Audiences, one data stream
Context
IKI Health, backed by Amura Ventures, is a Spain-based team building an AI-assisted health product around audio journaling and stress tracking. The brief was to take a new AI feature and bring it fully into the product across two audiences at once: everyday users on mobile and health professionals on an admin dashboard. The whole thing ran brief to handoff in about two months: nine core mobile screens, twenty-five-plus edge-case variants, four web dashboard screens, sixteen web edge cases, two distinct user flows.
The problem
The core problem was taking one stream of AI output and splitting it into two completely different interfaces for two completely different audiences. The feature returned dense, multi-dimensional data (user state, daily and weekly stress, voice metrics, emotion distribution) and the same numbers had to land in two places: a "record success" screen a non-technical user could read in three seconds, and a clinical view with enough depth for professionals to cross-reference against existing patient charts. Same data, two audiences reading at opposite speeds and trusting it in opposite ways. Around that sat a structural problem: the existing navigation was never built to hold stress tracking and audio input, so placement wasn't cosmetic. It forced a rethink of the app's core layout and flows together.
Process
- 01
Built a baseline that didn't exist
There were no structured design files for the live app, so I rebuilt it in Figma as a central reference everyone could point to, then ran a competitive analysis on audio-journaling apps and health data-viz patterns: to borrow what already worked and find where IKI could do something different without breaking conventions users understood.
The live app rebuilt in Figma: the central reference file the whole team could point to. - 02
Designed the AI feature from scratch
The audio journal flow was the heaviest lift: time-of-day states, recording edge cases, and the two result screens that came out the other end. The user screen reads top-down in priority order with the deeper data tucked below the headline; the clinician view treats the same data as a working tool, sitting inside the backend's established patterns where density helps rather than hurts.
Twenty-five-plus edge-case states laid out at once: scope is easier to see than to describe. - 03
Redesigned navigation in parallel
The old structure couldn't hold the new features without clutter, so I reworked the core layout and the new flows at the same time, placing each feature where it belonged in the user's mental model instead of wherever a slot happened to be free.
Old navigation versus the redesigned structure: placement decided by the user's mental model, not by free slots. - 04
Treated documentation as design work
Stakeholders and developers worked in Spanish; the PM was bilingual. So every screen got annotated and every flow got a logic map, letting the team review and approve asynchronously without translated meetings, and keeping the Spanish-speaking dev team unblocked instead of waiting on verbal handoffs.
An annotated screen and flow logic map: the artifact that let approval happen asynchronously across a language split.
The work
States shift by time of day and what the user has already done, meeting people where they are instead of restarting from zero.
The hardest call: the AI returns a lot at once, so the screen reads top-down in priority order with the deeper data tucked below the headline.
Show the trend, not the math. Users come back to see whether things are getting better or worse, not to read a chart.
The same data as a working tool, sitting inside the backend's established patterns so professionals can cross-reference against existing charts. Here, density helps.
The system grew rather than restarted: typography stayed, new components were added for the AI feature, existing ones extended to carry the load.
Outcome
Both audiences are served from a single source of data: a results screen a user can read in three seconds, and a clinician dashboard dense enough to cross-reference against existing charts, each speaking its own language while the underlying design system grew to carry them rather than forking into a parallel one. Because the thinking lived in clear written specs, the work was reviewed and approved asynchronously across a language split, without live walkthroughs holding anyone up.
- ~2 mo Brief to handoff
- 54+ Screens & edge-case states designed
- 2 Distinct user flows, one design system
- 0 Revision loops, approved async across a language split
Proof that the hard part of an AI feature isn’t the model. It’s deciding what each audience needs to see, and trusting them to read at their own speed.