Kindlebit
Product Engineering and QAPublicly listed capability

Find out what users need before you build it, then design the product so they finish what they start.

We run discovery with real users and stakeholders, resolve conflicting requirements into a prioritised scope, and deliver tested prototypes and a design system your engineers can implement.

Plan a product discoverySee the discovery flow

Kindlebit publicly lists this capability on its website or a third party profile. Named, approved project evidence is being compiled and will be added when Kindlebit confirms it.

Discovery to design

  1. Research
  2. Journeys
  3. Scope
  4. Prototype
  5. Usability tests
  6. Design system

Reference design. Components are options, not a statement of what is deployed at any customer.

Problems this service is built to solve

These are situations we expect buyers to recognise. Each one states why it happens, what it costs and how we would approach it.

Building features users do not need

A logistics startup spends four months building a route optimisation module because the founders were sure dispatchers wanted it. At launch, dispatchers keep using their spreadsheet, because the real pain was changing a booking after the truck had left.

Why it happens
Requirements came from assumptions and the loudest stakeholder, not from observing the work.
What it costs
Budget and months spent on low use features, and a late realisation that the real problem is still open.
How we approach it
We observe users in their context, interview across roles, map the current journey and rank problems by frequency and severity before any build decision, then test the riskiest assumptions with prototypes.
What to measure
Share of planned features backed by observed user evidence, and usage of shipped features in the first three months.

High onboarding abandonment

A SaaS product asks for company details, a billing profile, a data import and a team invite before showing any value. Half of new sign ups stop at the import step.

Why it happens
The flow was designed around the company's setup needs, not the user's first goal.
What it costs
Wasted acquisition spend and low activation.
How we approach it
We map the path to first value, remove or defer steps, test alternatives with a prototype and measure drop off by step in the live product.
What to measure
Activation rate, time to first value and completion rate by onboarding step.

Conflicting requirements

Sales wants a quick configuration tool, operations wants strict approval steps and legal wants an audit trail. Each requirement is reasonable, and together they produce a screen with forty fields.

Why it happens
Stakeholders optimise for their own goals and there is no shared model of priorities.
What it costs
Long debates, scope creep and a design that satisfies nobody.
How we approach it
We run structured prioritisation workshops with explicit criteria, resolve conflicts with evidence from users, and document decisions so they are not reopened without new information.
What to measure
Number of requirements with an agreed priority, scope change after sign off and time to decision.

Inconsistent interfaces

Three teams built three modules. Buttons, error messages, tables and date pickers behave differently, and every new screen starts from scratch.

Why it happens
There is no shared component library or guidance, and design and engineering work separately.
What it costs
Slower delivery, accessibility defects repeated in each module and a product that feels unfinished.
How we approach it
We create a design system with tokens, components, patterns and accessibility rules, implemented in code and documented for both designers and engineers.
What to measure
Share of screens built from system components, accessibility issues per release and time to build a new screen.

Solutions we engineer

Concrete capabilities, each with the need it serves, how it integrates, what you receive and the value to expect.

User research

Interviews, contextual inquiry, surveys and analysis of support and usage data, synthesised into insights and opportunity areas.

Customer need
Replace assumptions with observation.
Integration
Access to users, support tickets and analytics.
Deliverable
Research report and insight library.
Business value
Decisions based on evidence.

Journey and service mapping

Maps of user journeys with pain points, systems and handoffs across roles.

Customer need
See the whole experience, including the back office.
Integration
Operations and support teams.
Deliverable
Journey maps and opportunity list.
Business value
Shared understanding across teams.

Requirements and prioritisation

Story mapping, impact and effort scoring and release slicing, with decisions recorded.

Customer need
Turn many wishes into a clear first release.
Integration
Your product backlog tool.
Deliverable
Prioritised backlog and release plan.
Business value
Focused scope and faster start.

Wireframes and interactive prototypes

Low and high fidelity prototypes of the riskiest flows, tested with users.

Customer need
Test before building.
Integration
Figma and your brand assets.
Deliverable
Clickable prototypes.
Business value
Lower cost of change.

Usability testing

Moderated and unmoderated sessions with task success, time and error measures.

Customer need
Find friction early.
Integration
Participant recruitment.
Deliverable
Test reports and fixes.
Business value
Higher task success and activation.

Design systems

Tokens, components, patterns and documentation, implemented in code and tested for accessibility.

Customer need
Consistency and speed.
Integration
Your front end framework.
Deliverable
Design system in Figma and code.
Business value
Faster delivery and fewer defects.

Accessibility design

Design to WCAG 2.2 AA, with annotated specifications and testing with assistive technology.

Customer need
Usable by everyone and compliant.
Integration
Design and QA processes.
Deliverable
Accessibility specifications and audit.
Business value
Wider reach and reduced legal risk.

How we solve it

A delivery sequence built around architecture, testing, CI/CD and operational readiness.

Frame the problem

Align on goals, users, constraints and measures of success. Write down the assumptions that carry the most risk.

Research users and context

Interview and observe users, review data and map current journeys and systems.

Synthesise and prioritise

Identify problems worth solving, define the target outcome and prioritise scope with explicit criteria.

Design solutions

Create flows, wireframes and prototypes for the riskiest parts, and define the information architecture.

Test with users

Run usability tests, measure task success and revise until critical problems are resolved.

Define the design system

Build tokens and components, specify behaviour and accessibility, and prepare engineering handoff.

Support implementation

Review builds against designs, clarify edge cases and test with real data. Define the CI checks that protect design quality.

Measure and iterate

Instrument the product, review activation and task metrics, and plan the next improvements.

Solution in action: Discovery for an onboarding flow that loses half its sign ups

Reference Architecture An illustrative scenario. It describes how we would structure the work, not a delivered customer project.

Starting problem

A SaaS company sees half of new accounts stop before importing data.

Existing workflow

Sign up asks for company profile, billing, team invitations and an import before showing any outcome.

Improved workflow

Research shows users want to see a sample report first. The redesigned flow shows value with sample data, defers billing and team steps and offers a guided import. A prototype test confirms task success, and a staged release measures activation.

Half of new sign ups abandon onboarding.

Systems involved

Product analytics, support tickets, prototype tool, A/B testing.

Data movement

Funnel data by step, interview findings and usability test results.

Human decisions

Product owner chooses the scope. Users validate the prototype.

Automation opportunities

Funnel instrumentation and experiment reporting.

Exception handling

Users with large imports can skip the sample path and go straight to import.

Resulting user experience

New users reach a meaningful result in minutes and set up the rest as they need it.

KPIs to evaluate

  • Activation rate
  • Time to first value
  • Onboarding completion by step
  • Task success in usability tests

What you receive

Concrete deliverables for this service, written so you can check them against the contract.

  • Research report with insights and evidence
  • Journey maps and opportunity list
  • Prioritised backlog and release plan
  • Interactive prototypes and test reports
  • Design system in Figma and code
  • Accessibility specification and audit
  • Engineering handoff documentation
  • Measurement plan for post launch learning

Technology and engineering

Options we would evaluate for this service. Unless a group is marked as publicly listed on kindlebit.com, treat each tool as a proposed implementation option. Naming a tool does not imply a vendor partnership.

Design (proposed implementation options)

  • Figma
  • FigJam
  • Storybook
  • Design tokens

Research and testing

  • Maze or similar testing tools
  • Analytics tools such as Mixpanel, Amplitude and GA4
  • Session replay tools

Front end alignment

  • React
  • Next.js
  • Vue
  • Angular

Accessibility

  • WCAG 2.2
  • axe
  • Screen readers

Relevant Kindlebit work and evidence

We use the strongest evidence available and say which kind it is.

Publicly listed capability

Evidence status for this service

Kindlebit publicly lists this capability on its website or a third party profile. Named, approved project evidence is being compiled and will be added when Kindlebit confirms it.

Sources

See case study status
Reference ArchitectureInteractive demo with simulated data

Design system and onboarding flow for the AI SaaS product demonstration

The SaaS demonstration shows the product shell, tenant switching and an onboarding path built from a small design system. It is a demonstration, not a customer project.

Open the demonstration

Business outcomes and success criteria

These are the measures we would agree before work starts. They are criteria for success, not results from past engagements.

Activation

Share of new users reaching first value.

Task success

Completion and error rates in usability tests.

Delivery speed

Time to build a new screen from the design system.

Accessibility

Open accessibility defects against WCAG 2.2 AA.

Questions buyers ask

How long does discovery take?

A focused discovery for one product area usually takes three to six weeks. We scale it with the number of user groups and the complexity of the domain.

Do we need discovery if we already have requirements?

Requirements describe what people asked for. Discovery tests whether they solve the problem. If the requirements are already validated by user evidence, we can shorten or skip it.

Will we own the designs?

Yes. Deliverables built for you are provided in editable form, subject to the contract terms.

Can your designers work with our developers?

Yes. We deliver specifications and component code, and review builds against designs so intent is preserved.

How do you test with users?

We recruit from your user base where possible, run moderated or unmoderated sessions on prototypes and report task success and issues with severity.

How is pricing set?

By the number of user groups, flows, platforms and the depth of research and testing. We quote after a scoping call.

Related services

Industries where this applies

Discuss what your users need before you build it.

Tell us about the product, the users and the doubts. We will outline a discovery that answers the riskiest questions first.

Plan your product discovery Explore a demonstration