Avoiding design bottlenecks
One of the most frustrating parts of the product cycle is when the design is seen as a bottleneck. Sure, if you are over designing something in the early stages of your product, then it can become a blocker to your team. Often it is not the actual design work that is holding you up but the lack of a strong vision of where the product is going.
Some designers will sit on their hands and wait for other stakeholders to give them this vision. Great designers will be proactive in collaborating with their peers to help discover and flesh out the product vision. Here are a few techniques each stakeholder can use to help define the vision and keep the design process moving.
Product Managers
Don’t set unrealistic deadlines
In an agile world, your design team should be working 1–2 sprints ahead of what you are actually developing. If you feel like a feature has been properly vetted with users, requirements are clear, try to leave your designers at least 2 weeks to do a good job. A good job includes considering all the possible outcomes and arriving at the best solution. Asking for something to be delivered in a day will result in a design that looks like one day was spent on it. If you haven’t done any discovery with users, you’re going to need to leave even more time for design and you should include your designers in the process.
Set deadlines but don’t be a pushover
If you’ve provided your designers with a realistic deadline and they aren’t delivering, start looking for the root cause. Are they delivering 100% polished work for grooming? If so, this is not necessary to estimate a feature. Shoot for 80% with the promise that you will allow them time after grooming to polish the final product before implementation. If they insist on totally polished work, this is likely due to a lack of trust in your team. They don’t think you will let them finish the job. Insist on your deadlines but make sure you’re building trust with your design team.
What does 80% complete look like?
Generally, the user flow needs to be complete. You should be able to click or move through all of the screens in the flow. However, if the position of the button on the page changes, that’s not a big deal. Perhaps your original design used tables but you later decide to convert them to cards for mobile. These are a just a few things that might come out of a grooming session that would result in the design needing some changes.
Does your feature map back to the vision?
Before you drop something into the design backlog, make sure it maps to your overall vision for your product. Also, make sure you explain how it works in the big picture. It may be obvious to you but not to your design team. These types of bigger picture exercises help designers map a feature to the overall information architecture of the product to make sure it fits.
Don’t spread your designers too thin
The best setup is to have a dedicated designer on each of your scrum teams. When you put a designer on too many teams, this will naturally lead to bottlenecks. It will also slow you down because the designer has to constantly switch between persona contexts which can take time to wrap their mind around.
Don’t forget a system level designer
It’s also a good idea to have a system level designer who is not assigned to a team and is keeping an eye on the bigger picture of your product. This person’s primary function should be as an information architect who is watching how features cross over with each other. If the user transitions from stream 1 to stream 2 in your app, is the transition smooth? Is the Create paradigm the same across all teams and designs? You can quickly run into UX scaling issues if you don’t have the system level designer watching how the larger parts are coming together. If your transitions are not smooth, it can cause large amounts of UX debt down the road.
Designers
Don’t wait to be told what to do
If you are waiting on someone else to give you requirements, you are part of the problem. If you don’t have what you need, seek out your product manager and work out the details. If you need to whiteboard a flow, grab a meeting room and whiteboard what you need to get started. If you need to talk to users, help organize the meeting. You need to break down the walls between product and development and learn to build bridges. If you work as a team, then when bottlenecks occur, they are the team’s problem, not the designer’s.
Don’t over promise
Personally, I don’t like to say no to my teammates. However, sometimes this needs to be done if you are feeling like your workload is too large. If you are in a cadence of delivering work 1–2 sprints ahead but you have 20 open tickets for the next sprint, identify that as early as possible and approach your product manager. Ask product to reprioritize the tickets and move some of them out to a future sprint. Catch the problem before it becomes a bottleneck.
Participate in customer calls
You may feel like you don’t have time to talk to customers but getting the information from the horse’s mouth is super valuable. It will allow for stronger collaboration and quicker decision making within your team. You won’t need to do 4 versions of a design because you already know what the user wants. In the long run, this will save you time and increase your velocity.
Encourage the team to use design sprints
A design sprint can often be tough to get buy-in for as it feels like a large time commitment. In reality, you are front-loading some time at the beginning of a product or feature that will help you save time down the road. The goal of a design sprint is to produce a prototype that has been validated by users. If you hand a rough wireframe to a designer that is already user tested, the designer can move to high-fidelity mockups much quicker. Less back and forth with product management will be required which will remove the cursed bottleneck.
Try story mapping
Like a design sprint, story mapping allows you to map out a vision for a feature or product. It helps remove blockers because it gives the designer a map of work to follow. If story 1 is complete, they can move onto story 2 without having to engage with a product manager unless collaboration is needed. Mapping out stories in this manner is also super beneficial for information architecture. It gives the designer a higher level view of where the product is going and allows them to identify common components, template or visual design themes that can be reused to maximize the UX of your product.
Shoot for 80% done
As a designer in an agile world, one of the biggest things you need to learn is that you should NOT shoot for 100% done until after your team has groomed their stories. Set your goal at 80% and leave room for adjustments after the team has seen the work. There may be a technical constraint you were unaware of, a team member may have a better approach, the design may not get groomed and may be pushed down the road.
Imagine if you had spent several hours making your design just right. You’ll naturally be attached to your direction and not as open to change, which is an approach that won’t work in agile. Secondly, if you’re not worried about putting in the extra polishing time, you could’ve moved onto your next design task. This will help you build a backlog of design stories your team can pull from and avoid bottlenecks from forming. Product managers will love you if you have five 80% complete designs ready for them to groom with the team, versus one 100% complete design.
Don’t worry, you will still get to polish those designs. Once the team has accepted the design and estimated it, go ahead and push the design over the goal line before the actual sprint starts.
What does 80% done look like?
For this process to work, there are a few things that need to be solid and others that can be fuzzy. Your information architecture needs to be spot on, how the user flows through the feature, and how the design aligns to the use case you are solving for. The big picture of the design should be set; you should know which page template(s) you are going to use.
The more fuzzy parts are the fine details. Should we use a one column or two column layout for the text? Do we have all the required form fields for the form? Is their a secondary action or flow that needs some conversation before it can be completed? Everything doesn’t have to be on the grid and you can fix all the small stuff later.
Double down on collaboration
Often as designers, we silo ourselves into our comfort areas. Perhaps a Slack channel or WhatsApp group that only we have access to. We then communicate with product and development out-of-band via email or other channels. The problem with this pattern is you’re not being a team player within your larger group and you’re not building the relationships you need to be an effective designer. So jump into Jira or the developer Slack channel and start engaging with your co-workers there. Ask questions, give opinions, and this will lead to you building trust with your team.
Building trust with non-designers is perhaps the most important thing you can do for your personal design agenda. Product design is a two-way street and if you’ve built trust with your team, the next time you feel strongly about a design decision, you may not get the same pushback that you have in the past from your peers. In turn, they may provide you with a unique viewpoint that you can take back to your design process.
All of this increased collaboration will allow the team to run in a smoother manner. The design team is no longer a bottleneck holding up the larger team. In reality, there is an issue within the product that the entire team needs to work on together to solve. If you can achieve this level of trust, you can effectively eliminate the blame game and remove the roadblocks.
Developers
Don’t be afraid to talk shop
Designers working on web applications should be able to code basic HTML and CSS at a minimum. Some may have a basic understanding while others can code your entire front end. Don’t be afraid to talk to your designer about this to find their level of comfort with code. Be open to pointing them in the right direction and involving them. The more they understand what you do, the better designs for the web they will produce.
Involve designers in development meetings
Put a designer in your architectural and grooming meetings. The decisions you make on how data is delivered to the front end can have a large impact on the design and potential bottlenecks. For example, what if the designer would like to use inline validation for the UX of the product, but the backend is set up to do validation on the server? That’s a pretty big design problem that everyone should be aware of early. A designer could create numerous screens with inline validation designs to later find out they’re all invalid due to an architectural decision they were unaware of. Avoid these bottlenecks by including design in the high-level plan.
Involving designers in grooming meetings will allow you to address problems immediately when they pop up. Also, take the time to explain why something won’t work and you’ll avoid arguing over counting pixels or why 15 shades of grey are a bad idea. Less arguing leads to fewer blockers.
Participate in customer calls
As a developer, you have a unique point of view compared to that of product and design. Mainly the ability to bring everything to life. If your users want something that will be a technical challenge or may have constraints on the design, it is best for everyone to learn that early on. That way design can pivot to a solution that works for everyone and not create a bottleneck down the road.
It's also important for you to hear the motivations of your users from them directly. When product or design deliver a feature, it will help you to understand the underlying rationale better if you have heard the validation from the customer firsthand.
Build your design system early
A designer’s job is hard enough trying to juggle building and validating features with different stakeholders and users. When designers have to break their rhythm to work on the design system, it just slows everything down and creates bottlenecks. Yes, any good design system will change and have some maintenance. However, from day one you should have solid common components (buttons, tables, forms, etc…) solved so that you can worry about bigger problems. Solving the basics early also helps avoid the creation of tech debt.
The key to avoiding design bottlenecks is collaboration. Bring product and development team members into your design process and build the trust that is needed to design and deliver awesome products. When design becomes a blocker it is not a design team problem, it is a problem for all stakeholders. If you’ve successfully built bridges with your co-workers, product bottlenecks are a problem you can all solve together.
