OpenTable's design and development process guidelines

An interactive guide on how to work better together.

Away with the 'hand-off' and in with the ongoing collaboration
At OpenTable, we don’t believe in a final hand-off to engineers during the product development process. We believe that ongoing collaboration between engineers and designers is crucial to ensuring user-friendly and effective experiences.

This is a guide for engineers and designers on when and what to do to make working together seamless and productive.

Phase illustration
Phase 1
Gain context and ensure alignment
Phase illustration
Phase 2
Share and collaborate early and often
Phase illustration
Phase 3
Document and implement
Phase illustration
Phase 4
Phase illustration
Phase 5
Monitor and launch post-launch
Phase 1: Discovery
Phase 2: Collect feedback
Phase 3: Implementation
Phase 4: Review
Phase 5: Post launch
Phase 1
Gain context and ensure alignment
Get involved in the product brief

A product manager will write and share a product brief at the start of the project. As a designer or engineer, you should feel welcome to review and provide feedback on all parts of the brief. During development, continue to review the brief and designs to ensure you and all team members have a clear understanding of customer needs.

Align on vision with Story Mapping

To ensure your team is aligned on workflows and outcomes, you can run a story mapping exercise.

Story mapping is a practice of quickly building shared understanding and encouraging product, design, engineering and other stakeholders to define and prioritize the work. The exercise is helpful early in the process as a delivery tool, to support release planning and identify workflows without the need for designs.

If the engineering group is small and there’s time, you can choose to involve all engineers in discussion. However to save time, the PM and designer can outline the user flow and slices and then review and iterate with engineer leads.

The storymapping exercise was so beneficial for expectation setting with the product development team. It becomes a delivery tool, supports release planning and creates a shared discussion about workflows without needing to create designs.
- Jake Clements, Engineering Manager
Phase 2
Share and collaborate early and often
Request and provide feedback the right way

Share work early in the process to allow both sides to gain a deeper understanding of the problem and allow engineers to ideate with designers. As you share or provide feedback, remember these tips:

When requesting feedback remember to:
  • Provide context of user problems and business goals before sharing designs
  • State what type of feedback do you want (UX, UI, content, focused on specific area)
  • If unsure of a solution, walk through explorations
When providing feedback remember to:
  • Have an understanding on the context and goals before providing feedback
  • Frame your feedback around the user problem and goals
  • Lead with questions rather than problem solving
  • Provide rationale
  • Remain objective, and avoid personal ‘I don’t like…’
  • Be conscious of where we are in the process (eg. content not finalized in wireframes)
Refine designs with engineering in mind

While you may want to build the most flashy new experience, you’ll make a bigger impact if you understand the tradeoffs of feasibility and level of effort against user needs.

While discussing level of effort vs. user needs, ask:
  • Is there another way to solve this that can be less effort for engineering?
  • If we reduce scope, are we still solving the user problem?
  • How can the work be phased so that we ship fast and ultimately get to the final ideal product?
Collaborate and share content

Keep everyone happy by ensuring content is aligned by all stakeholders before it’s in engineering hands. For designers, that may mean using a source of truth document to track all content. Use this tool as a way to collaborate with stakeholders and also communicate to engineering on content updates.

Phase 3
Document and implement
Annotate all states

As a designer, you should document and annotate work so that engineers can quickly understand designs and begin implementation.

Leave no state behind

Be mindful of end to end user flow and all states including:

  • Interaction and behavior states
  • Error states
  • Empty states
  • Hover & selected states
  • Edge cases
  • Responsiveness
  • Translations
Reuse existing patterns

For designers, ensure you are using existing OTKit components using Figma libraries. If you don’t see a component in Figma, review the decision tree and come to OTKit Office Hours. We can help you!

Reference Buffet/CFE

When annotating designs, refer to existing patterns in Buffet/CFE. If it’s not in Buffet/CFE, communicate if it needs to be added, modified or AB tested. Before you add components to Buffet/CFE, make sure it is approved during OTKIt Office Hours.

Open communication is critical to the product development process. Finding the preferred way of keeping track of design or copy changes (whether that is Jira, Figma or Slack) upfront avoids confusion down the road.
- Briana Lee, Product Designer
Keep track of the work

During implementation, engineers and designers can use Jira to keep track of all upcoming work and changes

Provide details in Jira

Depending on the team, engineering or design must ensure Jira tickets are aligned to the design (eg. naming conventions / tokens). Use live embed Figma frames or attach images/screenshots into Jira tickets so engineers can reference current design as well as historical changes.

Communicate when designs have changed

Designs can change after engineers have reviewed the work. Avoid confusion by giving a deadline to engineers on when designs will be complete. If you do need to change after engineering has reviewed, over-communicate in Figma, Jira or Slack to ensure they’re aware of updates.

Phase 4
Quality check everything (and yes, we mean everything!)

Ensure the code is close to design, closely reviewing interactions and visual design. Design should document visual or interaction bugs in Jira or create a design QA document (example). Engineering and design should each prioritize tasks to determine tasks to do before or after GA.

Phase 5
Monitor and launch post-launch
Communicate if updates need to be made

After launch you’ll learn new things based on usage and feedback from users. If there are updates, document changes in Jira so that engineers can prioritize with other tasks. Where relevant, provide customer feedback with tickets to help provide context.