Helix — Digital Ecosystem
For this project I partnered with a global technology and engineering company employing more than 400 000 people worldwide. The focus was a 20 000-person department responsible for operational excellence and digital transformation.
The department was expected to drive digital transformation but couldn't find the information to do it — knowledge was scattered across 40+ platforms, search returned irrelevant results, and finding the right expert relied on personal networks rather than the system.
As part of the team I co-designed Helix — a Digital Ecosystem that unified knowledge, improved discovery, utilised the company's first internal AI assistant and gave employees a clear starting point for digitalization.
To protect privacy and confidentiality, all logos, company names, and other identifying details have been removed or replaced. These adaptations ensure compliance with privacy agreements and safeguard sensitive information.
challenge
Ineffective Search
Knowledge scattered across 40+ platforms. Irrelevant results meant teams often rebuilt solutions instead of discovering ones that already existed.
No way to find experts
Locating the right person for a project was slow and largely informal.
No clear starting point
Employees were handed a vague, top-down mandate to "drive digitalization," with no map of what that meant in practice.
solution
A digital ecosystem, built from the ground up
Centralized Content Hub
A single destination for digitalization topics and expert profiles. Every entry point led into one centralized search, eliminating platform-hopping.
Integrated Generative AI
Instant, relevant answers powered by organizational content.
“Getting Started” Pages
Topic-specific pages answering "what does digitalization actually mean for my area?", curating solutions, articles, expert contacts, events, and news around a specific topic instead of a vague mandate.
Impact
Helix launched in April 2024. In 9 months it’s achieved the following results:
12 730
Unique users
4.3
Feedback rating
13%
Faster solution finding
9%
Growth in digital skills
research
Defining who we design for
Before I joined, the team had run 40+ interviews and mapped four personas based on organizational role (board, manager, team lead, project manager) — but a first prototype tested poorly: unclear navigation, unclear content structure, and users unsure what task the platform was even meant to help with. The role-based personas turned out unhelpful too — people with very different job titles behaved almost identically.
After I joined, the team reframed personas around digital behavior instead of org role — Digital Explorer, Cititzen Developer, Expert Developer. My follow-up interviews with these groups, combined with usability findings from the failed prototype, shaped the content and site structure. From there, every major feature went through a clickable prototype tested with ~5 users before moving to production.
Pictured above: user interview notes
design
Rebuilding the landing page
The original prototype failed largely because of a lack of prioritization — everyone had ideas in slide decks with no shared roadmap, so the default was to include everything at once. A colleague and I ran workshops to structure user problems, stakeholder needs, and ideas into a roadmap tied directly to the scrum backlog. This gave our team grounds to cut two features outright: a solution-posting "Marketplace" (research showed users needed to find solutions, not post more) and "Smart Project Management" (out of scope).
Pictured above: prototype the team built before I joined
Two elements held steady from early on: color- and icon-coded content blocks (solutions, knowledge, communities — later expanded to other categories based on the users and stakeholders feedback) and actionable chips ("Find a solution," "Expand knowledge," "Join a community" etc.) that explained the platform's function without an onboarding flow. The layout around them took three rounds to get right:
Version 1. Prominent spotlight on top of the page, chips and default search results. Testing revealed that users ignored the spotlight and default results felt irrelevant and irritating.
Version 2. I suggested to push spotlight down and make it smaller, we also swapped chips for search prompts suggestions and made a shift into curated and personalized blocks. Test users didn't scroll past the spotlight and went straight to search; the curated content wasn't discovered and still felt irrelevant when asked about.
Pictured above: landing page concept exploration, version 1 and 2
Final structure — search results were moved to a separate page, since the team couldn't yet deliver strong personalization and users found the curated results irrelevant and irritating. Spotlight became small enough not to dominate, present enough for stakeholders. Chips were reintroduced since testing had proven they worked well — explaining the platform's purpose and giving users an initial search impulse. Getting Started was promoted to a direct landing-page shortcut instead of staying buried in navigation.
Result: landing page clearly communicated the platform's purpose with no lengthy onboarding required — chips showed what content users could search, and Getting Started pages promoted the company's digitalization building blocks, giving users a clear starting point across solutions, knowledge, and experts.
Pictured above: landing page final structure
Pictured above: search page mockup
Designing trust before designing AI
"Integrated Generative AI" was AskHelix — instant answers powered by organizational content, at a time when conversational AI was just becoming familiar to employees in Europe. The real challenge wasn't generating answers, but making sure they were accurate and specific to the company, not hallucinated.
I introduced visible sources: every answer cited the documents it came from, so users could verify instead of taking it on faith.
I also kept AI results on a separate interface entirely. Conversational search was still a genuinely experimental pattern with no established mental model, and we hadn't had time to thoroughly test result quality — despite stakeholder pressure to ship it as a marketing opportunity. Rather than blending AI answers into traditional search, I kept them on separate, clearly labeled experimental pages: the more cautious choice, but one where the risk of eroding trust in core search outweighed the convenience of a unified interface.
Pictured above: AskHelix mockup
The knowledge base itself was another trade-off. The safest option would have been to restrict AskHelix to internal, policy-approved content only — controlled, predictable answers, but too narrow for some use cases and not relevant enough for others. Rather than deciding on the user's behalf, I introduced a switch between an internal-only knowledge base (narrower) and a broader one (wider coverage, less certainty) — giving users control over that trade-off themselves.
Pictured above: prompts for users to get started
Pictured above: AskHelix settings
Other contributions
Profile & Notifications
Beyond the landing page and AskHelix, I independently designed the profile page and notifications feature end to end.
For notifications, the open question was how to group them in a way that made sense to users — content updates, community activity, and system alerts all needed intuitive labels. Rather than guessing at category names, I ran an open card sorting test to see how users naturally grouped and labeled different notification types. The results shaped the final grouping and naming used in the interface.
Pictured above: profile mockup
Pictured above: notification flyout
Pictured above: notification settings
Constrains
Working with what we had
Only a marketing brand library existed — no design system built for a dense internal product — so my colleague and I adapted a small system from it, keeping the platform consistent with the brand's visual language. I checked contrast ratios across the color- and icon-coded content blocks, making sure color was never the only signal — icons and labels always paired with it.
With limited development resources against a fixed release date, choosing what not to build mattered as much as designing what shipped: our team deliberately postponed behavioral personalization, adapting the landing page accordingly so that users still had a clear path to relevant content through chips, curated Getting Started bundles, and search — without the platform pretending to know more about them than it did.
Pictured above: News & Events, FAQ, Strategy, UX Getting started mockups
reflection
Constraints sharpen priorities. With three developers against a fixed release date, the team that decides what not to build ships something coherent — the team that tries to do everything ships the same cluttered, unusable prototype twice. Weekly sync with the product owner and dev team created fast feedback loops that surfaced technical constraints early, changing what got designed, not just what got built — several features were reshaped in these meetings before they ever reached a mockup.
Trust in AI is an interaction design job. AskHelix worked because of what surrounded the answer — sources, disclaimer, an honest choice about data — not because the model itself was novel.
Next Project
Store Assessment App
© 2026 Daria Behrens