🔍 Tracking your product discovery work

🔍 Tracking your product discovery work

Purpose of the product discovery board

  • Visibility on the workload of the Product Designers and Product Managers
    There are many ways to visualise and track all the work and effort that goes into fillling in engineering backlog with meaningful stuff, yet more and more teams decide on defining and following a company-wide discovery process that would give a clear guidance to the different domains for how and when to get involved into the early stages of the project lifecycle (pre-implementation).

  • Provide easy to follow Product Design flow
    Having detailed steps of the flow should make it easy to not miss anything important, as well as ensure other domains involved timely and at the right project stage. In the real set-up it would cross-link different templates, guides, other boards and spaces to complete the experience.

Board step Status Description Domains to involve Activities Input Output Deadline
Backlog — Backlog can be filled with:
  • Product Design tickets linked to the project/feature main tickets in the Business board
  • Ideas coming from the brainstorming sessions
  • User insight and feedback
  • Learnings from previous/current experiments
  • Actual or potential business need to explore
PD, PM, UXR, UXC PD grooming or a Product planning
  • Analysis learnings
  • Use cases
  • User insights
  • Any documentation with learnings
  • Problem statements
 Quarterly plannings
To pass to the next stage, ticket/project should
  • Have a clear problem definition
  • Have a responsible Product Designer assigned to it
  • Ticket should be linked to the Business board feature/project ticket unless it’s a very specific design only project or exploration
Exploration — Exploration is focused on understanding the problem better and gathering all the prior information. Projects the team has committed to go to this column, being ordered by priority. Tickets for a specific domain can be created (in their corresponding Jira spaces) and linked to the main project ticket in the Business board, as well as this ticket if needed. E.g.:
  • Data, to collect certain learnings
  • UXR, to synthesise insights on a specific topic
  • UXW, to explore content possibilities/needs
  • PO, to prepare some more detailed strategy, look into the business side, etc
  • PD, to start exploration such as benchmarking, best practices, etc
 PD, Data, UXR, UXC Data analysis, Comparative analysis, Heuristic evaluations
  • Past learnings
  • PRD
  • KPIs
  • Research
  • Scope of Work
  • Problem Statement
  • Documented research
  • Involvement plan
  • Content plan
 2 weeks before implementation sprint
To pass to the next stage, project should:
  • Have a full brief, including:
    • Clear problem statement
    • Expected outcome and Success Criteria
    • Deadline
    • Dependencies
  • Research and Content Teams should be consulted with and tickets for them should be created if needed
Concept Ideation Product designer facilitates brainstorming sessions and tries to create as much potential solutions as possible. It’s important to get everyone’s opinion early and be open to trying different things. Tickets for a specific domain can be created. E.g.:
  • Data, to validate certain hypothesis
  • UXR, to help running interviews or user testing
  • UXW, to finalise content, revisit layouts, etc.
 PM, CD, TL, RL, DL Sketching, Co-creation workshops, White boarding, Paper prototypes, Crazy 8s, etc.
  • Documented research
  • Involvement plan
  • Set of potential initiatives
  • Final KPIs
  • Potential solutions
  • Analysis of the solutions with Pros and Cons
UX testing PD uses quick testing methods to filter the solution and be able to select best one better. Sub-tickets for a specific domain can be created. PM, UXR Sketching, Prototyping
  • Research plan
  • Research script
  • Insights report
  • Recommendations
Finalisation Based on outcomes of brainstorming and UX testing, team selects one solution. Defining solution better through wireframing, creating user flows, JTBD, etc. PM, CD, TL, RL, DL Brainstorming, Kick-off
  • Analysis of the solutions with Pros and Cons
  • Solution Recommendation
  • Updated scope of work and execution plan
  • IA
  • Key user flows (happy paths)
  • Potential edge cases
  • Content Design, Data, Tech exploration being flagged and planned accordingly
To pass to the next stage, project should:
  • Have all flows clarified and documented
  • Have no blockers (missing content, early testing, tech unclarity, etc.)
  • All findings from Usability Testing addressed if applicable
  • Pass final kick-off with the whole team
Final design UI Based on accepted, and preferably validated, low fi wires, PD creates high fidelity ones CD, UXR
  • High-level solution
  • High-fidelity designs
Documentation Crucial aspects and decisions of design are being documented or visualised for easy understanding by developers. CD
  • Designs of all screens involved in the project should be final for all platforms
  • All content is final
  • Links to the animation examples and prototypes must be provided for all new features
 Team grooming
To pass to the next stage, project should:
  • Pass the grooming with the team
  • Content localisation document should be created
Handover Assets PD is preparing final designs and necessary assets for Developers Devs
  • High-fidelity UI
  • Complete deliverables check-list
Localisations Localisations should be finalised CD, PM
  • Document template
  • Finalised localisations
  • UI examples for unique or tricky cases
Clean-up PD cleans up figma file to ensure it’s easy to go through for Developers, PM, QAs PD links styles and components to the library, flags potentially new DS components or adjustments. DS PD Team planning
To pass to the next stage, project should:
  • Pass the planning
Ready for Dev Tickets that are ready to be picked up live here. Volume of the projects in this state helps to visualise refined part of the team's backlog
As soon as the team picks-up this project into the sprint, move the project into Design QA
Design QA
  • PD and PM closely collaborate with QAs and Devs and thouroughly check implementation whenever there is a new build
  • All deviations from initial plan are either fixed or documented as improvements for the next iteration
Done The feature is ready to be released
On hold / Archived The project is temporarily de-prioritised, missing crucial details to proceed or so on

< Previous | Next >

Next >