Share
Explore
Examples
Playbook
Below is a design playbook at Coda with potential ‘plays’ that we may choose to use on a particular story. When starting a new project, the team puts together a proposal for the plays that will be used based on the timeline and needs of the feature.
Stage
Play
Description
Effort
Use when
Discovery
15
Create a project brief
Ideally use all the time.
Prior Art
Review any prior art including old Figma’s, hackathon projects, research, related features etc. Can be helpful to meet with former project owners to review.
Use when prior art exists.
Community posts
Review relevant community posts including feature requests, complaints or current work arounds
Use when relevant community posts exist.
Competitive analysis
Capture a gif of the equivalent experience in similar competitors. Critique what works well and what doesn’t.
Use when we are adding a feature that competitors already have.
Current experience usability test
Run a usability experience either as an interview or on usertesting.com on the current experience.
Use when updating an existing experience to get a baseline.
Competitor usability tests
Run a usability test (in person, usertesting.com etc) of the relevant experience of a competitor to learn from and build up their experiences.
Use when there is a lot of variety between competitors with no clear idea experience.
Gather inspiration
Look for non competitors who solved similar problems and capture what works well. For example we drew inspiration from travel app’s filtering experience for Coda’s filters.
Use when possible and timeline allows.
Prior experience
Use prior experience either at Coda or previous jobs get started with limited discovery
Use when exists with limited timeline.
Internal experts
Get a brain-dump from internal experts (old story owners, key stakeholders etc.) on the specific story area.
Use when exists and timeline allows.
User data
Review relevant data from our mode dashboards. It may be helpful to setup a meeting with data team or ask for guidance.
Use when data exists and can help inform design decisions.
Intercom feedback doc
Our support team writes a small summary of all interactions with customers and categorizes by product area. Review the relevant feedback to get a sense of feature requests, common issues, user sentiment etc.
Use when improving an existing feature area.
Existing surveys
Review existing survey data including docX regular survey, activation survey, thoughts so far survey etc.
Use if survey questions are relevant.
Create new survey
Post a survey to the community with specific questions regarding the story.
Use for ambiguous stories when have time.
Exploratory interviews
Conduct interviews with customers before you design to help scope or frame problem. For example the locking story team conducted interviews asking users which parts of their docs they would want to do.
Use for ambiguous stories when have time.
Review feature requests
Review feature requests and ideas for the story area in the go/smooth doc.
Use when story involves a commonly requested feature.
ideate & create
7
Wallow meeting
Story teams gets together to frame problem and brainstorm design directions together.
Use when team is available or project could benefit from all disciplines participating in design process.
Define scenarios
Define a set of scenarios that need to be completed for a given story. These can influence what the designs and research focus on.
Use when scenarios are not clear or need to be prioritized.
Define personas
Define a set of personas for a given scenario.
Use when there are new personas outside or are more specific than our current maker, contributor, admin definitions.
Solo explorations
Dedicated story designer explores and produces mocks by themselves.
Typically used for most stories in addition to other methods.
Partner exoploration
Two or more designs pair up and meet regularly to share ideas and produce mocks together.
Use when have design bandwidth, with new designers or for large problems.
Async brainstorm
Solicit ideas from team members in a Coda doc.
Use for design problems that can be easy described offline with little context.
Design sprint
FA, story team or design team gets together for a multi-day concerted effort to generate ideas and create mocks.
Use for extremely difficult design problems with no clear solution.
Internal feedback loops
8
Design crit
Solicit feedback from design team at weekly design crit.
Appropriate for all stages of design process.
Slack pulse
Quick slack thread to vote on possible directions or solicit alternative design ideas. Typically sent to design or PD team channels.
Use when there is a clear set of simple options. Typically used for visual or layout feedback.
Eng feasibility
Meeting with story engineers or area experts to review feasibility of design directions.
Typically done for storys that require model work and done toward the beginning of creation process to avoid waisted loops.
Story team
Review with story engineers, designers & PM’s to solicit feedback or generate ideas.
Appropriate for all stages of design process.
PD sync
Review designs at weekly PD sync meeting.
Use when story impact multiple FA’s. or more complex complex problems that benefit from additional eyes.
Internal alpha
Enable feature for internal Coda uses on an adhoc or staging. Solicit async feedback in a Coda doc.
Use for all stories when feature is ready to be tested.
Bug bash
Dedicated meeting slot for FA area or company-wide participants to test feature and give feedback.
Typically used for features that require real time collaboration or when team needs to gather a lot of feedback in a short amount of time.
Catalyst
By-weekly company-wide meeting. Typically users sparring after multiple other internal feedback loops;
Have a problem that impacts multiple FA area or benefits from C-staff inpout.
External feedback loops
5
A/B testing
Code two or more versions of an experience and roll out to a subset of users. Review metrics to make a decision.
Use when there is a high degree uncertainty on the team and there is a clear metric that can make a decision (i.e. conversion %).
Private betas
Roll out a particular story to a subset of users. Typically they are asked to participate on surveys or interviews as part of beta.
Use for larger stories that may need more bake time or can benefit from actual user feedback.
Usertesting.com
Online resource where participants record a video of themselves reacting to an experience. Can be used with live code, ad-hocs, prototypes or paper mocks.
Use for detailed interaction questions. I.e. can the user complete the desire task.
Live usability test
Live 1:1 interview where participants walk through an experience and answer questions. Can be used with live code, ad-hocs, prototypes or paper mocks.
Use when feedback from experienced Coda users is needed.
Usability hub
Online resource where participants look at a single screen and give feedback. Can ask question or receive a heat map of first clicks.
Good for generating a lot of feedback on an isolated design question such first first click tests.
Craftmanship
7
Finalize mocks
Spend time on the craftsmanship of a design including spacing, alignment, fonts etc.
You like having a reference frame or just file nits till you get it right in code.
Copy review
Review the copy with Coda’s writers and brand folks.
Use when you have semi-complex copy or have difficult concept to explain.
Polish review
Review the final proposal or production code with the design team to look for craftsmanship issues.
Do this if you are not confident you caught everthing.
Nit bash
Either solo or with other designers file a series of ‘design nits’ that cover spacing, colors, fonts to get code aligned with the final mocks.
Do this all the time.
Design constancy
Look for any inconsistencies with other parts of the product. For example are we using the same font size for related UI’s. Engineering team should be comfortable in fixing other features details to get consistant.
Do this with the rest of the design team during crit or offline to catch any issues.
Refine animations
Prototype desired animations or work closely with an engineer to implement them.
Do this if your feature could benefit from animations.
Create assets
Create any new icons, illustrations, etc needed for the story.
Do this if your feature requires new assets.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.