How Jane Austen helped me teach Design Sprints

Sense and Sensibility and Storyboards

It’s interesting how popular Design Sprints still are as a topic almost four years after the Sprint book came out. I used to talk about them all the time, less so in recent times. I haven’t facilitated one in a while, but they were on my mind this week after reading a couple of books where the practice makes an appearance.

Beyond The Prototype by Douglas Ferguson is a lovely read building on the foundation of sprints and asking what happens after the sprint ends, and how to make it better. I was familiar with most of the content, but it’s still full of stories, advice, and overall, I found it very enjoyable.

Then there is Delta CX by Debbie Levitt. Oh dear. I wasn’t expecting such anger in a business book. It contains very detailed criticism on Design Sprints and other practices like Lean UX. I understand the points raised, I just don’t agree with the tone and the drama. But I don’t make a living as a UX Designer, so maybe I can not truly relate.

All these ongoing thinking around Design Sprints prompted me to write down some notes on when they worked (and didn’t work) for me. And I also thought it would be fun to share how I delivered sprints training with a Jane Austen flavor for a few months last year.

My history of sprints

As a tool, I find sprints highly contextual. The environment matters, as does timing and other conditions surrounding the teams. Design Sprints worked very well when I was coaching at King. They did what they were supposed to do: help us understand what to do next.

This Candy Crush feature came from a design sprint

The practice was adopted by teams developing new features for the original Candy Crush game. After some experimentation and tweaking, they became one of our favorite ways of approaching new work. I believe the development culture made it easy for us to adopt it:

• Everyone in the team felt like they owned the design.
• The team composition favored a pioneer mindset; people excited about prototyping and rapid iteration.
• We worked with a reasonably mature product and a decent understanding of what users may want. User research was not critical or a blocker.
• The sprint format created alignment and validation around the design that wouldn’t have happened otherwise. It indeed manages the need for constant conversation.
• We were able to follow up on the sprint with a user story map, which gave us an instant backlog for development.

I then went on to work with another company that had a desktop-based online game as a live product. Teams made a few attempts at using Design Sprints, and while useful, the practice never had the same overwhelmingly positive impact. Context matters. Some of the contributing factors I perceived were:

• Part of the team didn’t want to be in the sprints. There was a mix of attitudes and mindsets that created an inconsistent view of them within the group.
• The nature of the product and the problems this team wanted to solve made it hard to prototype quickly. The toolset didn’t enable the team to work as fast as they would’ve hoped. Despite trying smart alternatives, it never felt right.
• Development after the sprint was mostly linear. There was no A/B testing capability, the opportunities for revisions after launching were slim. The teams didn’t follow a real iterative process. Design up-front made more sense under these conditions.

Can we do some training?

While the actual product teams never adopted sprints, other people in the organization became interested. I ran sprints to solve challenges in areas such as people operations, and they were very well received. I suspected maybe more people could be interested in facilitating them. After confirming that this was the case, I went on to create a full-day training class to spread knowledge internally.

I wanted this class to be hands-on and entertaining. Earlier that year, I had attended a boot camp by Jake Knapp and Jonathan Courtney. I felt inspired by their practical approach. I wanted to do something that felt as dynamic and fun yet more aligned to what the teams I usually work with would face. And shorter than two days.

The workshop’s structure was fairly standard. I used Sharon Bowman’s 4Cs format. After a short introduction covering connections and concepts, participants would move on to concrete practice, be introduced to a “fake” product, and asked to solve a challenge following the sprint recipe in around six hours.

Since I usually work with game companies, I wanted to use a fictitious game as a product. At its core, this game wouldn’t be too removed from our day to day work. I wanted to retain a familiar feeling while also making it quirky and silly. At the office, we were borderline obsessed with Clueless, the 90s movie based on Jane Austen’s Emma. What would it be if we used the game equivalent of Austenland?

I invited people to imagine we were living in a world in which the “Jane Austen Cinematic Universe” was a thing. “If Marvel can do it, Jane can do it too”, I would tell participants, “our company has licensed the property, and we have created an online game around the theme”.

I needed to make sure the groups understood the value was not in solving the challenge but learning the practice. I thought this “whimsically weird” approach was maybe a good one to keep people from getting too carried away. And you can tell I had fun creating the material!

It was also necessary for me to communicate the context of where sprints fit in the development process. The way I see it, after receiving a problem to solve, I expect teams to start with Impact Mapping or Opportunity-Solution Tree before they even think of sprinting. And I want them to follow up with a User Story Map. As you will see, having all these concepts floating around during the training would became a problem for the class later on.

I ran a pilot workshop with a couple of groups, and while I had to tweak some content, I was more than happy with the engagement. Some of the participants reacted quite enthusiastically to the Jane Austen theme.

I felt like I wanted to share this with the world. Yay. I had already spoken about my experience facilitating Design Sprints, giving talks at various companies, but it always felt too passive. Now I had a workshop that people could experience. I went on to deliver this class in several organizations, both in Sweden and the UK, and with participants of diverse backgrounds.

Takeaways from the workshops

I collected feedback after each training. I saw what worked and what didn’t. In general, the training itself was well received and appreciated by people who already had an interest in the topic. And some people that didn’t know much about it, still came with curiosity and loved the playful aspect of the workshop.

Technically speaking, the most challenging part for me during the workshop was the final validation test. This is something teams would typically do on the final part of a sprint. I found that I was only able to have participants practicing it when we had more than six hours, and there was more than one group. People in these teams would test with each other; it was quite unpredictable and time-consuming. When pressed for time, I would go instead through some slides to explain ways to do validation testing, but obviously, it wasn’t as compelling.

I made the mistake of delivering the class to a few groups that were pushed into it rather than wanting to attend. When unable to control the messaging, I found there was a disconnect. I talked with people who immediately tried to explain to me all the reasons why this wouldn’t work for them. I was sympathetic to these situations, but my objective was never to convince anyone. I would point to all the material that exists out there on how to pitch sprints to management. I would also remind them that the tool is highly contextual. If the place and time are not right, chances are they wouldn’t have a great experience with it.

A change I made after a few workshops was to remove references to Impact Mapping, User Story Mapping, and other tools. I realized these terms are not as mainstream as I initially thought. It felt like I was throwing jargon around, and I didn’t have the time to explain them adequately. I moved them to the closing notes of the workshop, and I was happy to provide more information to those curious about it.

Strangely enough, despite focusing the training material around a game, the people most excited about the product being a game were those not directly involved with making games. Folks in the more traditional game companies were sometimes confused or even hostile towards the practice. No amount of warnings about how I wouldn’t expect anyone to design real-time gameplay experiences with it would prevent them from questioning its validity.

Diversity

I also found that unintentionally, I had created training material that challenged diversity stereotypes. May sound like a cliche, but the Jane Austen theme really was better received when the group was gender diverse or trending female.

Yes, this looks terrible but still not nerdy enough for some. Apparently needs guns.

I encountered a male-dominated group to whom I had to explain who Jane Austen was; they didn’t know, which fair enough, sometimes I can be a bit of a snob about these things but I can still understand. But then they complained about the fact this fictional game had no shooting, no combat, and no killing. I then observed how they struggled to come up with decent ideas to solve the challenges. Make of that what you want. I can blame a lack of empathy with the end-user, but it also tells me something about the state of diversity in the industry.

Over time, I became quite conscious of the diversity profile of the groups and even made plans to create alternative material for “male” environments. I never did, though, as I moved to other personal projects.

To wrap up, this was an exciting experience but an exhausting one as well. It’s very intense to facilitate 8 hours of this class, that’s why I stopped doing it after a while. I also learned that not everyone likes “whimsically weird” in their training. The good thing about the workshop is that save for a few slides, the rest was all agnostic of the product, and I could come up with alternatives in the future quite easily. Maybe going vanilla could be considered more user-centric, but honestly, I prefer to own the Jane Austen niche.