Iteration (and Compromise)

A year ago I was just starting out with design. I did a few projects, skimmed over dribbble, and read design articles. Often, these articles would explain how important iteration means to your designs. So I heeded their advice and within my Sketch files I would go wild with tons of different design styles and versions of the same thing. As someone just starting out I think it was good to go through all those designs. I’d see how contrast & rhythm would change with different font weights, colors, and spacing. It’s something I still do, but perhaps I just do a good chunk of it in my head nowadays. However, after hundreds upon hundreds of artboards, I have come to realise that iteration isn’t about how many designs I can come up with. Rather, it starts and ends with one of the most fundamental units in product design: a user story.

Creating and managing user stories is one of the most common tasks I’ll do at Gradescope. User stories are great because they are dense bits of information that contain actionable feedback. They are things that your users want to accomplish and its these needs that drive the development of the product. If you are a little unfamiliar with user stories* they look something like this,

As a grader, I want to filter the students I have to grade by section so that I can grade the students in my section.

At Gradescope, we have lots of these stories. Every time a user emails us with a problem or some piece of feedback we attach their names to stories relevant to their issue. Moreover, we organize these stories into flows using a web app called Clubhouse (its similar to Pivotal Tracker).

Here’s the details on how this works:

These newly created stories can exist in either a Design flow or a Dev flow. The Design flow contains stories that need to go through the hands of designers before they can make it over to the Dev flow. The Dev flow contains completed user stories from the Design flow as well as chores, bugs, and user stories that don’t need go through the Design flow. Each of these Projects also contain different statuses such as In Development, Ready for Review, or Completed. This way, a story can navigate from In Development to Completed within the Design flow and be Ready for Development within the Dev flow.

Clubhouse offers many ways to filter and view user stories however my favorite view is this one here. You can see each of the stores organized in their different states of activity. The stories move from Unscheduled all the way over to Completed (then later archived).

It’s a bit hard to describe the exact process but the importance here is the movement of these stories. As these stories move through Clubhouse, each step they slightly change. They change when a designer maps out the solution space. They change when new technical constraints are laid out by a developer. They change from feedback given by the CEO or from user testing or a new email from an investor. This is the iteration that those designers were originally talking about in those articles.

It’s less about coming up with hundreds of versions in the beginning and more about the hundreds of versions that you will make in response to these slight changes in the user stories. These changes will force you to make design decisions that stray from your original ideas and sometimes it will feel like you are making a compromise. It’s totally ok to feel this way! Discussing these compromises with your coworkers is the bread and butter of a designer’s job. It’s what makes your app better. Ultimately, its what makes you a better designer.

*If you are looking for some more guidance on how to make awesome user stories Heddy Stern has a great writeup on creating effective user stories.

Also, Catriona Cornett has sweet article on managing Usability Debt. I do think Clubhouse is a better way to track it than using an excel sheet though!