How does your team decide what to work on?
At Basecamp, employees write pitches that describe both a design problem and their proposal for solving it. Before each product cycle, the company’s leaders sift through every pitch and choose the proposals they think will deliver the most impact. 1
I’m not sure I fully agree with this approach. It conflates the design problem with the solution, creating an opportunity for teams to ignore major product issues if the pitch doesn’t solve them perfectly.
But the word “pitches” hints at something essential: the success of any given design project hinges upon selling it to the team. A designer’s success is not only predicated upon the quality and value of their work, but whether they can convince colleagues that the work is worth
I think it’s important to think of your work’s internal framing and perception as an essential part of your practice, instead of a distraction from “real design.” It’s a skill that takes time and practice to develop. Your aptitude for it affects your success.
You can practice effectively framing your work by naming design tasks in the team’s issue tracker. Naming a task poorly carries big consequences. I’ve seen teams ignore valuable projects for months, solely because those who best understood the task didn’t name it in a way that effectively communicated its impact. If your team has a backlog of hundreds of tasks, a product manager isn’t going to put in the effort required to fully understand every single one. They scan the name, make a snap judgment, and move on.
By contrast, good task names benefit both your colleagues and your future self. They help people find and remember projects that have already been identified as valuable, but haven’t yet been worked on.
With that in mind, here are a few rules I try to follow when naming design tasks.
A name should be clear enough to accurately describe the problem, brief enough to easily read at a glance, but still specific enough to distinguish it from similarly named tasks that may appear in your issue tracker’s search results.
Ideally, the reader shouldn’t have to click through to understand the nature of the task.
Explain the root issue that needs to be addressed, rather than your pitch for how you’ll fix it. Otherwise, you’re dooming the project to failure if people don’t like your idea.
Don’t be afraid to rename tasks over and over as your perception of the problem changes, or if you can think of an even shorter or more memorable way to summarize it.
If you’re optimizing your list of tasks for glanceability and quick recall, the name of each task should reflect the shortest possible summary of how the team currently understands it.
Sometimes, it takes a few tries to get the name as short as you possibly can. If you’re worried about keeping everything searchable, you can archive old task names in its comments to ensure your colleagues can find it.
This might be counterproductive within larger teams, who might be annoyed when they can’t find a task because you keep renaming it. But I’d argue that this is why issue trackers have a search feature: so that people can retrieve information they can’t easily find via normal browsing.