3 product designers. 25 developers. Helping thousands of event planners run better live events for millions of attendees around the world.
As you can imagine, being one of three product designers supporting a team of 25 developers who are building event technology to support thousands of event planners sometimes presents a bit of a resourcing challenge.
So how do we overcome time and resource constraints with a lean team?
Sprints. Planning meetings. Stand-ups and retrospectives. By incorporating these standard Agile practices that our developers already employ, we’ve turned a small team into a mighty team.
Great Design Doesn’t Happen in a Vacuum.
Our designers are embedded directly into our product teams, which also consist of product managers and full-stack engineers. While being dispersed in different teams can create a feeling of isolation from other designers, we all know great design cannot happen in a vacuum. So while we may be physically separated from each other, the design team functions as a unit, sharing support and resources whenever possible.
Dedicated Design Resources
Our product teams are completely autonomous. The teams are responsible for all stages of the product development process. The teams decide what to build and when to build it, giving product managers, developers and designers more ownership of their work.
By embedding the designers within these teams, we dedicate design resources to projects that the team deems most important. Each designer is responsible for their individual project timelines based on their team’s roadmaps.
Early Planning with Design Sprints
Aligned with our developer’s workflow, designers operate in 1-week design sprints. We run a weekly sprint planning meeting every Monday to plan our week and set objectives and deliverables. This meeting is key to ensuring that each designer has clear goals for the week and stays on track.
We time-box each step of our process. Our planning meetings give us the opportunity to collectively discuss the process requirements before the project has begun. Weekly sprints allow for rapid iteration cycles. The ultimate goal is to move a ticket through the entire process within the one-week sprint. Progress is tracked via a JIRA board:
Instead of spending weeks researching and collecting as much information about a problem as possible, we limit this step in the process to 1–2 days.
Whatever the designer can learn about the problem in that time is applied to a prototype and validated with users. If our assumptions were wrong, we roll the new learning into the next sprint and iterate (time-permitting). This keeps us agile.
Delivering Designs Just in Time
By following a similar sprint structure to our developers we are able to align our deliverables with their roadmap. We try to work 2–3 sprints ahead of developers, which allows us to take the time we need to thoroughly explore each step in our process. That said, if we work too much further ahead, we find ourselves revisiting the designs before development begins anyway.
Because this can be a huge waste of resources for a small design team, it’s imperative for us to carefully plan our process so we are delivering detailed, validated designs to our developers just in time.
To stay on track and solicit feedback in a timely manner, we use 1 daily meeting and 2 weekly meetings as our main touch points.
Design Stand-Ups Cultivate Collaboration
It may seem obvious, but the best technique we employ to combat working scattered throughout the office is getting together often. We foster a highly collaborative work environment where we encourage designers to sit together to work through problems in person.
It can be disruptive at times, but we feel the pros far outweigh the cons. Several times a day I send and receive Slack messages asking for a quick critique. I’ve never been turned away.
In addition to those informal meetings, every morning we hold a 30-minute daily design stand-up. This helps us start our days off on the right track. The focus of the meeting is two-fold: early critique and process/timeline alignment. If a design discussion runs long we know we need to schedule a longer meeting where we can dive deeper into the problem or adjust the schedule for the particular project. Daily meetings mean decisions happen faster and less time is wasted on a designer’s internal conflict over how to move forward.
These meetings also serve as a way to pool design resources. While our style guide (more on that in a future post) helps ensure we aren’t reinventing the wheel with every component or pattern, there are still instances in which designers need something new. Early discussion helps identify these instances and ensures we are considering all the possible use cases across our products, which ultimately saves time and effort by not having to refactor later.
Gathering Early Feedback is Imperative
With a small team, you can’t afford to spend a few days heading in the wrong direction. So, gathering early feedback is imperative.
With that in mind, we run a weekly design critique meeting on Friday afternoons that involves the larger product team, including designers, product managers and the CTO.
During these meetings:
- All participants gain a shared and deeper understanding of the problem,
- Designers share their research and learning from user testing sessions,
- The product team collectively provides feedback.
The meetings happen at the end of our design sprints so we can incorporate feedback immediately in our next sprint.
Aligning Design with Development
On a weekly basis, each product team runs a Show and Tell. During these meetings, all team members share what they are working on and provide valuable feedback to each other. For the designers, it’s a chance to show early iterations of a design.
This helps align design with development, by making sure that design is technically feasible within the project timeline. It also allows the developers to be more involved in the design process and encourages a real ownership mentality towards the product.
This is only the beginning for us as we look for more ways to improve our process and deliver the best products we can with limited resources.
Co-opting Agile practices for our own design needs has proven to be a huge success for our small team. Without our design sprint planning meetings and stand-ups, we wouldn’t be able to accomplish half of what we do. We will continue to run design retrospectives and look for further ways to improve and deliver more value out of our small (but mighty!) team.