Designing a complex B2B workflow, then building the system behind it.
This project started as a 56-hour recruitment exercise for Sonova, a global hearing aid producer. The brief was broad: design a B2B portal concept for hearing care professionals across up to seven functional areas, while considering accessibility and demonstrating how the experience could scale through reusable components.
I had no access to users or internal product data, so I used competitive analysis and publicly available solutions to form working hypotheses based on assumptions and domain knowledge (personal experience working in the hearing aid industry), rather than validated user findings.
The challenge became less about designing up to seven screens and more about creating one coherent experience across interconnected tasks.
Working hypotheses
Although I was about to accelerate the initial design using AI, I needed a set of assumptions to design against. I treated these as hypotheses to be validated with end users at a future stage of the project:
01
Clinicians are constantly interrupted.
They need the ability to save drafts and pick up exactly where they left off without losing configuration data.
02
Ordering likely prioritises accuracy over discovery.
Clinicians usually order the same products repeatedly, so I designed around efficient product selection rather than exploratory browsing.
03
Context is easily lost.
Managing multiple patients, brands, and warranties simultaneously requires persistent, visible summaries.
From brief to rendered interface in hours, not weeks.
Once I was done with my research, I framed the problem around cognitive overload, missing step indicators in most workflows connected with purchasing, and product-focused software rather than process-focused solutions. In my opinion, these were the biggest unsolved challenges in most publicly accessible solutions across the hearing care industry.
I shaped the solution and used Figma Make to rapidly explore how the portal could be structured across six functional areas given in the brief: main dashboard, ordering, order history, patient records, warranty/service, and training. The goal was not to let AI make design decisions; it was to compress the translation from brief to something visible, so I could evaluate, critique, and structure it properly.
The AI-generated prototype acted as a starting point. I reviewed every screen critically against product logic, realistic B2B tasks, accessibility requirements, and navigation consistency. I still had to decide: what information matters most, how tasks should be prioritised, where friction occurs, and which patterns should become reusable components.
As you can see, the experiment gave good results when it came to the functionality of the product, but the rendered components were uneven and did not follow the same design patterns.
Below is the initial output compared with the final screens.
Dashboard, initial design (AI output)
Dashboard, final (Designer-refined)
From screens to system, making patterns reusable.
After the prototype established the product surface, I shifted focus from screens to structure. I broke the interface down into repeatable patterns: navigation, buttons, form fields, status labels, cards, tables, alerts, tabs, step indicators, and action panels. Each had to work consistently across the portal and scale to new areas without rebuilding from scratch.
Due to the time constraint, I had to limit my scope to 2–3 ready components to be able to present the concept of the component library. One of those components was the button system presented below, where I focused on variants, including edge cases such as when the button is disabled.
Buttons system
The system in context, from ordering flows to patient records.
The next component I focused on was a stepper indicator. The ordering flow is where the component system does its most visible work. A six-step stepper guides clinicians from patient selection through brand, product, configuration, review, and order, with a persistent summary panel keeping context visible throughout.
As you can see, the button hierarchy is explicit at every step: primary for the forward action, secondary for per-card selection, neutral for reversals, and tertiary for escape hatches (Save Draft).
Select brand in order checkout (Designer-refined)
Select product in order checkout (Designer-refined)
Four decisions that shaped the whole system.
In order to create one coherent system, I chose established design principles to set the rules for the product and guide heuristic decisions.
01
Consistency
Similar actions and states look and behave the same across the portal, regardless of context or portal area.
02
Scalability
New portal areas can be designed without rebuilding patterns from scratch. The system carries the structural decisions forward.
03
Accessibility
Clear hierarchy, readable contrast, visible states, and predictable interaction patterns are built into every component from the start.
04
Hierarchy in practice
One primary action per page. Secondary for supporting actions. Tertiary for utility. The system tells a story the user never has to think about.
Reflection & next steps
The most important next iteration would be to validate the ordering flow end-to-end with actual hearing care professionals, mapping their current process, identifying where the portal creates friction or clarity, and testing the configuration step in particular.
The component system provides a foundation, but real workflow validation would tell us whether it’s the right foundation.
