Process Overview
- Matt Birtch
This document aims to outline the responsibilities and areas of ownership of product designers in the feature development lifecycle.
First, some terminology…
Workstreams
Workstreams are broader themes to address multiple customer needs/pains. For example, Federated workspaces might be considered a workstream.
Features
Features are specific solutions that address the needs/pain identified. For example, Shared Channels would considered a feature.
The Double Diamond Process
Moving forward, we will loosely be following the double-diamond process for product development. We will see various workstreams happening in parallel and each progressing through the double diamond phases in their own timelines.
Discover (owned by PMs)
Although product management will be taking greater ownership in this part of the process as they shift their emphasis towards research, Product Designers will also have a part to play.
Research the problem space
CS and PMs will conduct customer interview calls where appropriate to hear direct feedback on pain points and to understand needs. Designers can be included in these calls where possible to hear directly. Designers will have access to recordings and notes.
PMs will be interviewing customers to validate roadmaps as well as validate potential new offerings. Designers will have involvement in these conversations and will be informed of the outcomes and solutions that need to be prioritized.
Outcome: participation from customers to work with us and commit to adopting solutions
Data synthesis and analysis
Customer feedback will be processed and analyzed by PMs
Gather telemetry, productboard data to aid in validating the problem
PMs share trends and insights gathered from various data sources in reports.
Outcome: hypothesis on workstreams to focus on based on customer data
Define (co-owned)
Establish the workstream’s requirements
PMs will coordinate with Designers and Engineers to determine scope
High-level design explorations for features within the workstream
This is early-stage design work that should not include all the nuanced edge cases and full-fledged solutions
Product designers can lead and facilitate idea-generation activities to help source potential ideas. This may or may not include activities like:
Design sprints: larger time investments (1 week) with small and mid-sized groups
Intended for larger problems where more concentrated design effort may be needed
often follows its own double-diamond structure over a week
Brainstorm: smaller time investments (2-4 hours max) with small and mid-sized groups
Where possible, engage customer success in this process as the proxy for our customers
Start with sketches or low-fi wireframes for quick ideas
Work with PMs and engineering leads to estimate the level of effort for potential solutions
One-pagers are created for proposed features (example one pager)
On-pagers are Owned by PMs, but designers are responsible for providing feedback and links to design work
Key screens for solutions are provided for customer validation purposes (not full spec yet though)
Outcome: Validation from exploration of scope/requirements of workstreams with customers
Design/Develop (owned by design & engineering)
Feature planning and design (owned by design)
At this point in the process, we’re focused on features rather than workstreams. Each feature would follow the remaining part of the process
Kickoff the feature project with Design and Engineering
Start a new channel for focused communication about the feature. e.g. “Feature: Bookmarks Bar”
Identify the "jobs to be done" and create user flows
Conduct competitive research
Designers dive deeper into the explorations done in earlier stages (that supported the one-pagers) to cover use cases, edge cases, and scenarios not yet accounted for.
Build prototypes
Share work-in-progress in design crits with design team
Share work-in-progress with engineers, PMs, QA in the Spec Reviews channel
PMs will connect Designers and Engineers with interested customers to validate functional designs once ready
Conduct user testing or usability studies as required
Get writing input from Technical writers - share Figma link to DWG Working Group channel
Document the User Experience. Designers will be on point to develop UX functional specifications including:
unhappy paths, edge cases
clarify ambiguous scenarios
consider onboarding experience for new features
work with engineers and PM to identify phases of the project (MVP+)
work with engineers to verify and finalize functional requirements
Outcome: Feature planned and designed with engagement from interested customers
Development (co-owned by design and engineering)
At this stage of the feature lifecycle, a product designer’s job is not done. They will continue to ‘usher’ the feature along by participating in the following:
Respond to ad-hoc questions as they come up during development
UX/design reviews on Pull Requests
Helping coordinate QA resources if needed
Deliver (co-owned)
The solution is ready to ship. UX may support in providing assets for the following:
Animations or videos that demonstrate the feature - for use in blog posts, or social media
Support in visuals needed by marketing, training or documentation
Follow-up
Once a feature has released, there are often follow-up tasks to truly close off a project.
Schedule meeting to review adoption metrics and user feedback
Plan improvements and next iterations
Design System: bring newly created components in to the Compass Design System