We’ve all heard the phrase ‘content is king,’ and it’s especially true for designers who want to build products and services that effectively get the user exactly what they’re looking for with minimal friction. But design and content teams don’t always work in harmony, and Steve Fisher said that can be disastrous. He’s the founder of The Republic of Quality, a UX and content strategy firm with a secret weapon up its sleeve: design and content sprints that bring designers and content strategists together.
At Adobe MAX, Steve will break down his methodology in his workshop Running Your Own Design and Content Sprints. Ahead of that, we asked him to share some of the why and how design and content teams can come together to make great things happen.
What does a design and content sprint look like?
We know design sprints are a really useful tool. They definitely speed up communication, ideation, as well as general understanding for any project at all. One of the things I started to notice, though, with how they were being talked about, is that people weren’t really talking about the content that was involved.
Any good designer knows design is informed by its content, not the other way around. So, with the sprints I’ve been running, we’ve always been taking what I call a content-design approach, or even content modeling, where everything is informed by the actual content we’re going to be working with throughout the project.
How do you start?
We don’t know every piece of content we’ll have in the beginning, but we should be able to identify who we’re working for (who the audience is), what their needs are, and then, if it’s a pre-existing product, we’ll be working with some existing content (that may change over time). We take those, break them down, and try to understand who the users are and what the business needs from them.
From then, we begin to model out an interface, a concept, an idea around what we’re trying to communicate and how we can be successful in meeting the user’s needs. So it’s this really rapid ideation process that, typically for me, lasts between three to five days. Sometimes it’s less days, but never more.
Who should be part of the content and design sprint?
The team makeup matters a lot. In ideal world, you should assemble your sprint team with:
- A user experience lead (perhaps heading up the project)
- A content lead (a writer, strategist, or subject matter expert)
- A tech lead (unless it’s not a tech-related project)
- A decision maker (who make calls related to budgets)
- A graphic designer (involve them from the beginning, and not just after the fact)
Everyone in the room should have an equal voice (obviously the decision maker, with their knowledge of budget, has the final say). It’s not always possible to have six different people taking on six different roles in every scenario. Sometimes one person has to perform more than one role. But these types of representations make for a healthy interdisciplinary team within the sprint.
Don’t look at it as bringing different teams together. During sprints, we’re all in it together. The magical part about that is that its kind of like interacting with siblings. You may have a disagreement, but you’ll make it to the other side and your relationship will be stronger. Communication is easier because you’re spending 3-5 days in a room, putting up post-it notes, working out every idea. These sprints also bring teams together, which you can’t accomplish very easily any other way.
How do you make sure your time effectively?
Before we even get rolling on anything, we establish a framework for how we’re going to come to an agreement on things. We’re never looking to compromise in our decision making, we’re looking to agree on everything. It’s not some magical rainbows and hugs agreement; it’s saying we have established the vision and we know the audiences.
After we’ve identified our users and vision, we create a set of guiding design principles (like values, based on those users’ needs).
Finally, we set some high-level goals for the project. They don’t need to be specifically measurable, they really are overall goals; for example, saying ‘hey, we want to improve the customer service response time for 20% in this release.’
We complete these tasks in a cascade. It goes, people first (audience), vision (based on the audience’s needs), design principles (based on that vision), then goals based on all of the above. It can be really tempting to jump to our goals, but you always need to start with the way before you can get to the how.
Once that framework is set, it makes it much easier for everyone involved to make decisions that we can all agree on. It takes opinion and preferences out of the picture and allows us to think outside of ourselves, which the world is sorely in need of now.
And how does the end user benefit from this process?
The team communicates better, together, and they’re able to make better decisions for the user. They’re focusing on their user base throughout the sprint and, ideally, at the end of the sprint they bring in some of the users for testing.
Another approach is to bring in a team member who is part of your user base. You can bring them in for portions of the sprint to help ideate and answer questions about your audience because they are part of that audience. It doesn’t always work, since one person can’t really represent an entire group, but it is useful to have that initial feedback before you go through your first morning of user testing.
Why are you so passionate about running design and content sprints in your work?
I run these on every single project I do, and they always lead to that ‘aha moment’ where the team starts to fire on all cylinders. Communication that would have taken weeks via emails or phone calls starts to happen quickly. That co-presence is needed to get to a certain place.
The best outcomes are often that we walk away with a concept and documented idea we can begin to work on immediately; a point that normally would have taken us weeks to get to.
It can be seen as an expensive process because of how many people are in the room at one time, but really it’s far more expensive to not do this and can result in miscommunication and projects getting really drawn out.