Design Operations Framework at Dooly

Start Here

Welcome to the Dooly Design Process Guide. For any new folks or existing team members, this is where you can find information on our design processes, tools that we use, team ritual information, and more.

This artifact walks through the operating system behind the Dooly design team: how we approached product design, how we spent our time together, the tools we relied on, how we invested in team development, and how we built shared understanding of our users.

Each chapter covers a distinct layer of how design operated at Dooly. Use the table of contents above to jump to any section, or read through in order.

How We Approach Product Design

Design philosophy, product development flow, risk framing, jobs-to-be-done, and foundational UX thinking.

How We Work Together

Design rituals, recurring meetings, collaboration norms, and how communication worked across the team.

Rituals and recurring touchpoints

As designers we needed to carve out time to get work done, align as a team, and for things like eating lunch. To help with this, we carved out a 3-hour block of time daily for just the Design Team. This was Design Time — a protected window where the entire team was together, working in a shared space.

Design Time consisted of three main parts:

• Design Standup. 10 minutes each max to present, 5 minutes to ask questions. A quick sync on what everyone was working on and where they needed input.
• Team Rituals. Design jam, design critique, and other structured collaboration sessions that rotated through the week.
• Flex Time. Your time to do your thing — eat lunch, heads-down work, or follow up on conversations from standup. As a team we wanted to make sure we were staying balanced.

The exception was every other Wednesday for team planning, and Design Team retros happened bi-weekly.

Meeting architecture

Meetings at Dooly fell into four categories depending on the audience and purpose. Design rituals were the team's own time. Beyond those, designers attended company-wide syncs, R&D alignment sessions, and squad-level ceremonies that varied by product team.

Collaboration model

To recreate the experience of being in the same office and reduce barriers to communication between designers, the team had a persistent Design Time Zoom link that everyone stayed in for the entire duration. This was the virtual equivalent of sitting together in a studio — you could turn to someone and ask a question without scheduling a meeting.

The Zoom was organized into breakout rooms that gave people control over their work environment. Need to focus? Move to Heads Down. Need to pair with someone? Jump into a meeting room. Want to hang out and work together? Stay in Main Room.

Non-designers could be invited into Design Time meeting rooms for collaboration. External meetings and user interviews were ideally scheduled before or after Design Time to protect the block.

Communication norms

Communication at Dooly moved between a few key surfaces depending on urgency and audience:

• Slack was the default for async coordination — scheduling critiques, sharing updates, and keeping the team informed about what was happening across squads.
• Zoom (Design Time) was the synchronous space. If something could be a quick conversation instead of a thread, you had it live.
• Figma served as both a design tool and a communication surface. Comments, annotations, and shared files made design work legible to collaborators without requiring a meeting.
• Notion and Confluence held the durable documentation — meeting agendas, retro notes, onboarding guides, and shared references that outlived any single conversation.

The goal was clarity over volume. Every recurring meeting had a documented purpose and agenda. Design rituals were structured so that work moved between people and sessions without relying on anyone remembering to follow up.

Tools & Setup

Discovery tools, ideation tools, Figma usage, delivery workflows, onboarding setup, and where documentation lived.

Team Development

Professional development, growth structures, strengths, and how team capability was supported.

Understanding Users

Product domain context, user research, mental models, and the user understanding required to do good work.

References / Notes

Acknowledgements, legacy material, and source references used to shape the system.