Case study / Internal product
Internal UI Source of Truth for Design, Development, Product, and QA
A custom internal component documentation and discovery tool, built from scratch in Angular and shaped by a familiar Storybook-style experience.
What is CodeBook?
CodeBook is a custom internal Angular application that documents and renders the reusable UI components used across product applications. It brings live examples, supported variants and states, usage guidance, implementation references, and accessibility checks into one shared workspace for design, development, product, and QA.
Built within the same Angular codebase as the shared component system, CodeBook renders the maintained implementation rather than recreating it for documentation.
It follows a familiar Storybook-style browsing pattern, but its product structure, documentation model, and implementation were created from scratch for the organisation’s workflow.
Cross-functional value
CodeBook creates one shared reference across the complete UI delivery lifecycle, helping design, development, product, and QA make better decisions from the same maintained component system.
Experience how components are implemented, verify design fidelity, and confirm that design intent holds across real states, interactions, and technical constraints.
Reuse maintained components with confidence using clear standards, supported variants and states, and implementation-ready references.
Understand what already exists, verify that product screens use standard components, and separate genuine product needs from unnecessary one-off variations.
Validate UI against a stable baseline for expected behaviour, variants, states, and accessibility, making testing more consistent and less subjective.
Why it needed to exist
UI knowledge was fragmented across tools and people, making standards difficult to locate and decisions difficult to verify.
Goals
The aim was to create a more standardised, discoverable, and repeatable way for teams to make UI decisions, reuse established patterns, and validate implementation with less ambiguity and rework.
Establish one trusted baseline for component behaviour, states, usage patterns, and styling decisions across applications.
Help teams quickly understand what already exists without searching through repositories, design files, chat threads, or individual memory.
Give designers a reliable view of implemented components so design intent can be validated against real behaviour and supported states.
Help product teams distinguish between an existing standard, a valid enhancement, and an unnecessary one-off variation.
Provide QA with a stable reference for expected component states, interactions, validation behaviour, and accessibility expectations.
Reduce repeated clarification, duplicate implementation, and late-stage correction by aligning teams around the same reference earlier.
My role and ownership
I identified the workflow gap, defined the product direction, designed the experience, and led frontend implementation, validation, and rollout.
My scope covered product vision, information architecture, documentation structure, frontend delivery, manual testing, enablement, and final decision-making.
Product thinking
The product decisions reduce friction around choosing an existing standard and make deviations deliberate.
Core product principle: Make the standard path the easiest path.
Discoverability
Organise components, states, and guidance around how teams actually search, reducing dependence on scattered references and individual memory.
Fidelity
Use live implementation as the source of truth, so decisions are based on actual behaviour rather than static mock-ups or assumptions.
Predictability
Document loading, disabled, error, empty, and validation states early so expected behaviour is not left open to interpretation.
Actionability
Pair examples with guidance and implementation references so teams can move directly from understanding a component to using it correctly.
Alignment
Give design, development, product, and QA one shared reference for discussing, reviewing, and validating UI decisions.
Reuse
Reduce the effort required to find and apply an existing pattern, making consistency easier than building another one-off solution.
UX approach
Sidebar navigation frames the workspace, a compact toolbar controls mode, the preview leads, and supporting documentation sits below.
Core features
Together, these capabilities form the complete documentation and discovery product.
Organises components and references into browsable sections so teams can quickly understand what already exists.
Renders the shared Angular component directly so its current implementation can be inspected.
Documents supported variants and important states such as disabled, loading, error, empty, validation, and focus.
Explains when to use a component, when not to use it, and which defaults or patterns are recommended.
Surfaces configurable options and examples so developers can apply the standard component correctly.
Provides practical implementation references that reduce repeated searching and manual mistakes.
Displays components in applicable visual themes within the same documentation workspace.
Makes accessibility expectations and component-level checks visible inside the documentation workflow.
Gives each component a stable page URL that can be opened and shared directly.
Product preview
A typical component page brings the live implementation, supported variants and states, usage and implementation guidance, and accessibility checks into one shared reference. The Button walkthrough below will show how these parts work together.
Technical architecture
CodeBook is implemented as a modular feature within the existing Angular codebase. Route selection opens a component-specific page that renders the maintained shared component alongside reusable documentation panels, interaction utilities, and accessibility support.
Architecture overview
The architecture keeps the maintained Angular component at the centre of the documentation experience. The CodeBook feature shell combines route-driven page configuration, live component rendering, documentation panels, shared interaction utilities, and accessibility support within one consistent workspace. This keeps the documentation connected to the maintained implementation, reducing the risk of documentation drifting from the components used in the product.
Decision
Decision
Decision
Decision
Decision
Decision
AI-assisted workflow
AI supported implementation, debugging, exploration, and refinement. Its output remained subject to human review, testing, and final approval.
01 / Define
AI did not determine what needed to be built or why.
02 / Accelerate
AI output was treated as input for review, not as a final answer.
03 / Validate
Nothing was complete until it was reviewed, tested, and validated in context.
AI increased implementation velocity. Human judgment protected product quality.
Adoption and enablement
CodeBook became useful because it could be referenced during the moments where UI standards are decided, reviewed, and validated.
Short walkthroughs and lightweight internal storyboards helped reinforce a “CodeBook-first” habit before recurring questions returned to chat or individual memory.
Outcomes
The observed value was a more consistent reference point for routine UI decisions, reviews, onboarding, and validation.
The clearest signal of value was a change in team language: "Check the CodeBook standard."
Learnings
Building and introducing CodeBook clarified where shared standards succeed or fail in daily work.
Internal tools still need strong UX, clear structure, and user-centred product thinking.
Documentation becomes useful only when teams trust that it reflects the maintained component system.
Loading, disabled, error, empty, and validation states need the same attention as the default component.
Cross-functional consistency improves when design, development, product, and QA work from the same reference.
Accessibility is more effective when it is built into component guidance and validation rather than added at the end.