Tipshelf — UX Case Study for Internal Knowledge Sharing
A self-initiated concept for helping distributed teams capture, find, and reuse company-specific knowledge. Based on my experience in distributed teams and an earlier reflection on knowledge-sharing habits, the case study covered fictional personas, a structured post template, tag taxonomy, role-based user flows, wireframes, high-fidelity screens, and an interactive Figma prototype. Created around May–July 2025 as a self-initiated case study.
Where this experience applies
This UX case study explored how company-specific knowledge could be structured for sharing and reuse, supporting both the people contributing knowledge and those trying to find it later.
- Capturing company-specific knowledge in a reusable form
- Making insights distributed across Slack and project documents easier to find
- Designing a consistent structure and taxonomy for contributions
- Balancing contributor effort with reader comprehension
- Exploring asynchronous knowledge sharing for distributed teams
- Turning an internal-tool concept into user flows and a prototype
Overview
Tipshelf is a concept for an internal tool that helps teams share and reuse undocumented, company-specific knowledge. I created it as a self-initiated UX case study around May–July 2025. The problem framing grew from my experience working in distributed, cross-functional teams and an earlier reflection on knowledge-sharing habits. I created fictional personas and scenarios, a structured post template, tag taxonomy, sample posts, role-based user flows, wireframes, a mini style guide, responsive high-fidelity screens, and an interactive Figma prototype.
Background
Knowledge about internal frameworks, company-specific tools, internal processes, and context-dependent solutions is often difficult to find through public search and may never become part of formal documentation. A final decision may remain in Slack or a project document, while the options considered, failed attempts, team context, and reasoning behind the decision are harder to recover. New team members and people working across teams may then need to investigate the same problem again. Tipshelf explored how a team could preserve the outcome of problem solving together with its context, attempts, decisions, and lessons, allowing other members to find and reuse the knowledge later.
Core Challenge
The design challenge was to treat contribution effort, information structure, discoverability, reuse, and continued sharing motivation as parts of one system.
- Company-specific knowledge may remain undocumented or limited to individuals and project groups
- Decisions may be recorded without the reasoning and experimentation behind them
- Similar troubleshooting may be repeated by different team members
- New team members may have limited access to previous problem-solving processes
- Contributors may be unsure what to write or find sharing too time-consuming
- A growing collection requires several ways to discover related knowledge
- Contributors need ways to see whether their posts were useful
- The platform needs criteria distinguishing company-specific knowledge from generally available information
Fictional Personas
- Lisa: a junior UX designer who recently joined a distributed team and wants to understand how earlier design decisions were reached
- Anna: a mid-level UX designer who contributes to team practices and wants to share the process behind design problems and solutions
- Ethan: a frontend engineer who wants to document company-specific UI, state-management, and API solutions together with their reasoning
Design Scope
Post Template
- Title: a clear, searchable title
- Context / Situation: where and why the issue occurred
- Problem / Friction: what was difficult, unclear, or unsuccessful
- What I Tried / What I Thought: attempts, alternatives, and reasoning
- Outcome / Insight: results, lessons, and possible reuse
- Tags: tool, context, theme, tip type, and role
Tag Taxonomy
- Tool: Figma, Jira, Git, React, Slack, and others
- Context / Situation: Remote, Async, Onboarding, Legacy System, and others
- Theme / Target Area: Flow Design, Accessibility, API Handling, Error Handling, and others
- Tip Type / Nature: Mistake, Workaround, Lesson Learned, Debug Process, and others
- Role / Perspective: Designer, Engineer, PM, QA, Support, and others
Core Interfaces
- Post List: filtering by tag, role, and context; sorting; post previews; recently commented posts
- Post Detail: structured content, Helpful reactions, comments, related posts, and back navigation
- Post Submission: template-based fields, inline guidance, multi-tag selection, and submission feedback
- Responsive layouts designed for desktop and mobile
Contribution Guidelines
- Knowledge related to internal tools, company frameworks, and internal processes
- Context-dependent solutions that are difficult to find through public search
- Contributions explaining the reasoning and experimentation behind an implementation
- Knowledge likely to be reusable by another team member in a similar situation
- Topics already covered well by public documentation remain outside the intended scope
- Short-lived issues and low-reuse contributions remain outside the intended scope
Fictional Sample Posts
- UX design example: improving comment visibility in a Figma mobile prototype
- A hypothetical asynchronous-review case using comment layers and visual anchors
- Frontend example: handling asynchronous API state in a React form
- A hypothetical request-collision case exploring debouncing, cancellation, and save timing
- Both examples were created specifically for the case study and are not anonymized company incidents
Approach
Framing the Problem from Experience and Reflection
I used my experience working in distributed teams to examine how company-specific knowledge becomes difficult to share and reuse. Ideas from an earlier reflection were then developed into a concrete internal-tool concept.
Creating Fictional Personas and Usage Scenarios
I created Lisa, Anna, and Ethan to examine both knowledge-seeking and knowledge-contribution needs. Their roles, experience levels, team contexts, goals, and usage scenarios were developed into separate user flows.
Structuring Knowledge for Reuse
The contribution template organized each post around context, problem, attempts, outcome, and insight. This kept the conclusion together with the reasoning process, allowing another team member to compare the post with their own situation.
Designing Several Paths to Discovery
The taxonomy separated tool, context, theme, tip type, and role. Multi-tagging allowed the same contribution to be reached from different perspectives.
Exploring Contribution Boundaries and Motivation
I created guidelines distinguishing company-specific, reusable knowledge from information already available publicly or likely to become outdated quickly. Helpful reactions, comments, related posts, contribution visibility, and team recognition were explored as hypotheses for supporting continued participation.
Designing Role-Based User Flows
For each persona, I mapped contribution, browsing, search, related-content discovery, and feedback. The flows assumed asynchronous use across distributed teams.
Developing Wireframes and a Prototype
I created wireframes for the Post List, Post Detail, and Post Submission interfaces, then developed a mini style guide, responsive high-fidelity screens, and an interactive Figma prototype.
Design Highlights
Preserving Decisions Together with Their Reasoning
Each contribution included the situation, problem, attempts, outcome, and insight. This structure was intended to help readers understand the conditions around a solution before reusing it.
Supporting Contributors and Readers
The submission form used structured fields and inline guidance to give contributors a clear starting point. The detail view presented contributions in the same order, supporting comparison across posts.
Providing Several Discovery Paths
Tool, Context, Theme, Tip Type, and Role were kept as separate tag dimensions so users could browse the same knowledge from several directions.
Defining the Intended Knowledge Boundary
The concept focused on company-specific, context-dependent knowledge. Publicly documented topics, short-lived issues, and low-reuse contributions were treated as outside the intended scope.
Exploring Feedback as a Contribution Signal
Helpful reactions, comments, related posts, and visibility were designed as signals that a contribution had been useful. Whether these mechanisms would sustain sharing behavior remains a hypothesis requiring validation.
Outputs
- Problem framing and product concept
- Three fictional personas
- Role-based usage scenarios and user flows
- Structured post template
- Five-part tag taxonomy
- Contribution guidelines
- Fictional sample posts
- Wireframes for Post List, Post Detail, and Post Submission
- Mini style guide
- Responsive high-fidelity screens
- Interactive Figma prototype
What Was Completed in the Case Study
- Developed experience-based observations into an internal-tool concept
- Designed contribution, browsing, search, related-content discovery, and feedback as one connected flow
- Created a reusable post template and multi-dimensional tag structure
- Used three fictional personas to examine knowledge-seeking and contribution paths
- Produced wireframes, a style guide, high-fidelity screens, and an interactive prototype
Screens & Design Material
Post List View
A list interface supporting filtering by tag, role, and context, along with async-friendly scanning.
Post Detail View
A structured view presenting context, problem, attempts, outcome, and insight.
Post Submission Form
A template-based contribution form with inline writing guidance.
Role-Based User Flows
Contribution, browsing, discovery, and feedback flows for Lisa, Anna, and Ethan.
Mini Style Guide
Colors, typography, and interface elements used across the list, detail, and submission views.
What This Work Demonstrates
This case study organized company-specific, hard-to-find knowledge as a product concept covering contribution structure, tag-based discovery, contribution and browsing flows, and participation signals. I developed the work from problem framing through personas, scenarios, information architecture, wireframes, a visual system, and an interactive prototype.
Validation Scope & Future Hypotheses
The personas, scenarios, sample posts, and expected effects were design hypotheses based on my experience and reflection.
- Whether the post template reduces contribution effort
- Whether the taxonomy helps users find relevant knowledge
- Whether Helpful reactions and comments support continued contribution
- Whether contribution guidelines maintain information quality and reuse value
- How recognition within a team affects knowledge-sharing behavior