See all works
SaaS B2B Enterprise UX Knowledge Management 0→1 Product

Designing a knowledge transfer platform so critical expertise doesn't leave when people do

great2know came to me with a product concept and a clear organisational pain: when people leave or move roles, the institutional knowledge they carry walks out with them. I designed the end-to-end product experience for a SaaS platform that captures, structures, and transfers that knowledge before it disappears.

My Role

UX/UI Designer

Company

great2know · Germany

Year

2024

Type

Enterprise SaaS · 0→1

Engagement

Part-time

great2know — platform overview

great2know — centralized knowledge transfer platform for enterprise personnel transitions

Section I

Knowledge walks out when people do — and organisations have no system to stop it

Personnel transitions happen constantly in organisations of every size — departures, promotions, lateral moves, restructuring. What doesn't happen consistently is the transfer of knowledge that leaves with the person. The processes they owned, the context behind decisions, the relationships they managed, the workarounds they knew — all of it either lives in email threads, in personal files, or only in their memory.

The traditional response is "write it down before you go." This fails for predictable reasons: departing employees are focused on their next role, not documentation; the people who need the knowledge don't know what questions to ask; and whatever does get written down is typically unstructured, incomplete, and inaccessible to anyone who comes looking for it six months later.

great2know was founded on the insight that this is a systems problem, not a motivation problem. What organisations needed wasn't a reminder to document — it was a structured platform that made knowledge capture a natural part of the transition process itself, and made that captured knowledge findable and usable by successors.

4

Core platform modules designed from scratch

3

Distinct user types with different needs and mental models

0→1

Full product built from concept to shipped experience

Section II

Three people, one transition — each needs something completely different from the platform

The first design decision I made was to resist the temptation to design for a single generic "user." A knowledge transfer event involves at least three distinct people with fundamentally different relationships to the process, and collapsing them into one persona would have produced a product that served none of them well.

The Knowledge Sender

The departing or transitioning employee. They're the source of everything valuable — but they're also time-constrained, emotionally in transition, and often uncertain about what's actually worth capturing. The platform needed to guide them through structured capture without making the process feel like a performance review. Contextual prompts, templates, and a clear scope definition (what this role actually owns) were the design anchors for this user.

The Knowledge Receiver

The incoming employee or successor. They need to get up to speed quickly, but they don't know what they don't know — which makes traditional documentation almost useless. The platform needed to surface relevant knowledge at the moment it was needed, not dump everything at once. Role overviews, topic-based organisation, and search were critical for this user.

The Transition Manager

HR, team leads, or department heads overseeing the transition. They need visibility into whether the transfer is actually happening — not just whether someone has opened the platform. Completion tracking, gap identification, and the ability to prompt for missing content were the key design requirements for this user.

The design challenge wasn't making knowledge transfer easy. It was making it inevitable — embedding the transfer process so deeply into the transition workflow that skipping it became harder than doing it.

Section III

Structure before screens — mapping the knowledge model before designing anything

The most important work I did on this project happened before any screen design. I spent the first phase mapping how knowledge actually moved in organisations — what types of knowledge existed, how they were connected, and what made some of it transferable and some of it not.

This produced a knowledge taxonomy: the framework that determined how information was categorised, linked, and surfaced in the product. Processes (how things get done), context (why decisions were made), relationships (who to contact for what), and institutional memory (undocumented history that shapes current behaviour) — each needed different capture mechanisms and different display patterns.

Four design phases

01

Capture

Structured templates and contextual prompts guide the knowledge sender through documenting processes, decisions, and relationships — without requiring them to know what matters most.

02

Structure

Captured knowledge is organised by the taxonomy model — topics, roles, and urgency levels — so it can be navigated by someone who doesn't know what they're looking for.

03

Transfer

The receiver experience surfaces relevant knowledge in the right sequence — role orientation first, then operational depth, then edge cases and institutional memory.

04

Verify

Analytics for managers show transfer completion, content gaps, and time-to-productivity benchmarks — turning an invisible process into a measurable one.

Section IV

Four modules — each designed as a coherent part of the same system

Module

Knowledge Repository

Centralized capture and organisation of critical role information by topic and urgency — structured for both input by senders and navigation by receivers

Module

Role Overview

Structured handover templates showing what each role owns, knows, and does — giving incoming employees a complete picture of the role before day one

Module

Transition Analytics

Completion tracking, content gap identification, and productivity benchmarks — giving managers visibility into transfer progress without micromanaging

Module

Onboarding Flow

Guided experience for knowledge receivers — sequenced content delivery that surfaces the right information at the right stage of onboarding

great2know — knowledge repository and role overview screen great2know — transition analytics and onboarding flow

Knowledge repository and transition analytics — two of the four core platform modules

Section V

What the platform delivers when it works

The value of great2know isn't visible during the transition — it's visible three months later, when the successor is operating independently and the organisation hasn't lost productivity to a knowledge gap that should have been bridged. That's a hard thing to design for, because the success metric is something that doesn't happen: the call back to the departing employee, the undocumented process failure, the relationship that went cold because no one knew who to call.

The design I delivered gave the platform the foundations to make that case. Structured knowledge capture makes the transfer measurable. Role overviews reduce the ambiguity of the first weeks. Analytics make the quality of any given transition visible to the people responsible for it.

Reduced

Knowledge loss risk during personnel transitions

Measured

Transfer completion — for the first time, transitions are trackable

Faster

Time to productivity for incoming employees with structured onboarding

Enterprise SaaS design Knowledge taxonomy Information architecture Multi-role product design 0→1 product

Other projects

Tiki · Feature

Aging Inventory Report

Weallnet · Mobile App

Content Platform Redesign