How we used a Jobs To Be Done framework to iterate on our newsletters
It’s easy to create a newsletter. Platforms like Mailchimp have made sure of that. But it’s much harder to iterate on a newsletter. Trust us– we’ve gone through many iterations of our newsletter product design and content design and it doesn’t get any easier to decide what to change and why.
One tool we use to help us with those decisions is “Jobs To Be Done,” a framework used to better understand what motivates people to subscribe, continue subscribing, and pay us for our work. Our UX Lead, Michael Schofield, introduced it to us a few months ago.
“Tools like user personas are good exercises, but in all honesty, when it comes to practical decisionmaking, they tend to be useless or left on the sidelines,” he said. “If you identify the end to which a service you provide is the means, you can make really sound, strategic decisions about how to facilitate that journey regardless of your user’s demographic or what persona they fit into.”
In other words, everyone who walks into the hardware store to buy a drill has a very similar end goal, and it doesn’t always matter who they are, where they came from, or what their persona is. Most drill purchasers want to buy a tool so they can easily drill holes in things and screw things into those holes. (Buyers may want the drill to do other jobs too, but this basic one is a pretty safe bet.)
So our goal to iterate on the product based on the user’s end-goals, and Jobs To Be Done is a good way to discover those goals and to test our assumptions about them. It’s basically broken down to this sentence structure, which you can read more about it here.
So we started talking to our users. We started with user interviews and asked our users to read a recent newsletter with us and talk us through what they found interesting and/or didn’t enjoy so much. We also used insights from our Net Promoter Score (NPS) surveys, which we send out regularly to our readers in which they rate how likely they are to invite a friend to subscribe and give feedback on what they like or what could be better about the newsletter.
Based on that feedback, we designed these JTBD for our newsletter readers:
- When I open the newsletter, I want to understand what’s going on in my city in five minutes or less so I can win at the watercooler.
- When I open the newsletter, I want to explore new places, meet new people and try new things in my city so that I can find my place in it and build a meaningful connection with it.
- When I open the newsletter, I want to learn how I can be civically active in my day-to-day life so that I can contribute to solutions in my community with my time, money or effort.
This framework played a large role in informing our content design strategy– the types of newsletter content we make and how we organize it for our readers.
After defining our jobs to be done, we revisited each of our newsletter sections to determine whether they satisfied our users’ jobs.
For example, because users want to read the newsletter quickly and to win at the watercooler, instead of the five paragraph-long summaries of stories in the city, we now choose one story we think our users need to know for the day and write a longer summary about it. Also, because our users love knowing what they can do with the stories we share with them, we always try to include resources on how to get involved as part of every piece of original content we make.
As great as this user-centered framework is though, we also have to make decisions based on our capacity and resources, which can sometimes feel at odds with what users will love.
In our latest newsletter design iteration, we created a “card” as our design component. Schofield said that it allowed the tech team to create a standard, consistent look and feel for our websites and newsletters without having to be the best designers on the block. The tradeoff? Some users have told us the newsletter looks more boring and feels more corporate.
We want to revisit ways to bring back design elements that reflect each of our city brands’ homegrown and delightful feel. Because we were very focused on “utility” in this set of iterations, delight wasn’t surfaced as a specific job, and now we know it should be!
The card design has a lot of benefits for us internally. It helped reduce our technical debt (i.e. it’s faster for our tech team to make), paved the way for specific content to be displayed to specific segments of users, and will also inform future iterations of our newsletter promotion ads. So we’ll keep it, but also work in our next set of iterations on making the format feel more delightful and testing it with users.
There’s certainly not one single framework to use when considering how to iterate on a product. What other frameworks or tools have been useful for you? What other factors do you take into account when iterating on a product? And how do you measure the success of product iterations? Reach out! I’m at anika@whereby.us. I’d love to chat more, and hopefully, we can learn together.
Anika Anand is the director of product at WhereBy.Us and cofounder of The Evergrey. This post is part of a series on how WhereBy.Us works in an effort to share what we’re learning, and to learn from others across the industry. Thanks to Michael Schofield for chatting about his UX work and to WhereBy.Us COO Rebekah Monson for editing.
Interested in WhereBy.Us coming to your city?
Tell us where we should head next.
Sign up for our WhereBy.Us city newsletters!
The New Tropic
The Evergrey
Bridgeliner
Pulptown
The Incline
