Don’t blame the designer
“When is the design for the new site going to be done?”
As managers, it’s easy for us to blame our design team for missing deadlines. But are your designers really slowing down the project?
What’s really slowing down your team
If it’s not your designers, why didn’t your project launch on time?
Not giving enough time for exploration
Design isn’t a simple A → B process. It looks more like this:
When you’re creating time estimates for your project, make sure you build in time for the designer to explore different options.
“You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.” — Steve Jobs
During this stage (also called ideation) it might feel like not a lot is being done, but be patient! Once your designer has found the right concept to move forward with, you’ll find the project goes a lot faster.
“Building things the right way takes time and thought.” — Dave Stadler, Quick Left
Unclear requirements
Writing good specs is important. How can a designer start work on a mockup if they don’t understand what the scope of the project?
“Most of the times it turns out that spec writers haven’t really thought everything through, and it’s usually only when we start designing and developing that we end up in trouble, as a lot of the spec seems to have holes.” — eagerMoose on Stack Exchange
Too often, stakeholders haven’t really thought through what they want. A designer needs to understand what the client needs, why they need it, and how it will be used.
At Sprintly we use a Mad Libs-style form for creating user stories:
“When you do something in Sprintly, you have to enter it as: As a ___, I want ___, so that ___. The fact that you can’t add a feature without entering it in that fashion [forces you to do it properly].” — Darren Rogan, the Hack and Heckle podcast
Using this form helps set a specific direction for a specific feature. It also ensures that the scope of a given story is kept small.
Changing requirements
The second biggest complaint we see from designers? Constantly changing the specs once work has begun.
This Hacker News user, cognivore, had a good metaphor to describe this:
Us: “Well, we just got the roof on and all the walls sheet-rocked!” Them: “We want all the walls moved now.”
This is largely a symptom of not properly planning work items before putting them in the work queue.
One method for avoiding changing requirements mid-stream is to create interactive mockups before actual development begins:
“We would be faster if we prototyped more thoroughly. Sometimes we don’t think hard enough about the user flow or interactions, so we end up having to re-think it after implementation, and then redevelop it.” — Tobin Harris, Director at Pocketworks
Just because we work in an agile way doesn’t mean we can change the scope whenever we want. Ideally, anything you learn mid-sprint should be captured and considered for a future iteration.
Another way to discourage changing requirements (and scope creep) is to have ways to forecast progress. In Sprintly we have a feature that allows us to anticipate how many more days of work are left before a job is finished:
If new tasks are added, our Progress feature lets us know how many more days of development we can expect.
Context switching
The final road-bump in your process is likely context switching. This can take a few different forms:
- Designer is 50% of the way through Task A when you go to his desk and ask him to switch to Task B.
- Designer is 50% of the way through Task A when you ask him to also do Task B.
The problem arises when you, as a manager, switch your designers to new tasks mid-stream. If your priorities are always shifting, you’re introducing huge costs to your team.
Joel Spolsky really hammers this home in his post on context switching:
The real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a employee who is deeply submersed in a project.
Take responsibility
As managers, it’s our job to provide an environment where designers can succeed. Before pointing the finger at designers and blaming them for a slow delivery schedule, we should examine ourselves first.
Here are some steps you can take to ensure you’re not slowing your team down:
- Give your team time to explore: trying different approaches is an important part of solving a design problem. If you only give your designer time to pursue one avenue at the beginning, you will likely pay the price later in the project. Allow your team to pursue the best option!
- Help your team understand the vision: work with your team to define a vision for how you’re going to make users’ lives better. Be clear about the outcomes your users need. It’s important to have designer buy-in. Their passion for a project can be a huge driver for velocity.
- Write well-defined project descriptions: use a template for each task you create. Designers should have the power to say no to a task, until it has a detailed description.
- Reduce context switching costs: don’t interrupt your designers! Before sending them an email or making a request, evaluate the cost to their productivity.
Most of all, be very careful about blaming your designers for being “too slow.” It’s very likely that it’s your workflow that is slowing them down.
Want to try Sprintly out with your design team? Sign-up for our 30-day free trial. No credit card required!
The original post ignited some passionate conversation on Hacker News, Reddit, and Slashdot.
Originally published at sprint.ly on November 19, 2014.
