Block & Flow: Using Design Sprints to make something people love
Introduction
Building a product or service is hard. I have great empathy for the people who do it. I enjoy speaking to people about how they create and build a product or service. Inspired by these conversations and my experiences, I would like to share what felt like a special and successful period of developing our iOS app, Block & Flow.
Let me first explain where we were trying to go. We were early and working towards a version 1 for the App store. The criteria that we were aiming for, was to create an app people loved. Like would not be good enough. We were searching for an intense, strong reaction to our app. We wanted someone to be upset if we were to take it away from them. Such a reaction is essential if you want someone to tell others. At this stage we cared about the intensity, and not the number of people. Our aim was to create a ‘wow’ experience for a few people, then afterwards we could figure out how to find more people.
In the case study, I cover techniques and tools that we used as we looked to make an app people love. These include Design Sprints, crowdsourcing our design and user testing. The reader will also see how an awkward design evolves into a design that users consistently praised.
If you like any of the ideas, try them, adapt them and find out if they work for you. Enjoy reading.
Introducing Block & Flow
Block & Flow is based on the thinking and approach that has improved my life the most over the last five years. It has helped me learn new challenging skills such as programming. It has meant ideas turned into something tangible. It helped me through difficult challenges in life such as my dad’s illness and death from cancer. It makes me keep going. It makes me more capable each year than the last. It has been overwhelmingly positive and rewarding. I enjoy being helpful, and want others to have an equal, or better , experience than my own.
The most meaningful experiences are often the scariest. It is hard to go towards your fears, build your character, and to seek out the experiences that elevate your life. Fears are natural, but they limit us. An example is when we say to ourselves, ‘I could never do that’. There are many, many diverse fears that our brains easily create. The challenge is to not let fears be our master. Instead use them to guide our direction and to see them as a challenge.
The psychology is as follows. If you experience a series of small successes, your fear diminishes and you start to believe that you can accomplish what it is that you set out to do. Block & Flow’s purpose is to build a person’s confidence and for them to ultimately get done what they set out to do. Be this writing a book, starting a business, learning a skill, or any other of the many meaningful choices.
How does Block & Flow create these small successes? Its essence is that each time you complete a block, a 25 minute countdown, then this is a small success. The design makes it easy for you to build up these small successes in the day, then over a week. The aim is that these weeks become months and the months turn into years. I believe people can surprise themselves with what they can accomplish over the long term. Block & Flow’s job is to get someone started and to keep them going.
You can find Block & Flow on the App store here
Who ‘we’ are
Initially the team was two of us working full time, myself and a talented iOS developer/ all round smart person. My skills are varied and include design, programming, copywriting, psychology and strategy.
After the Design Sprint covered in this case study, we added a freelance designer to the team.
We also had another capable freelance programmer available for web and backend work when required. I was lucky, he loved what we were doing, and was / is a fantastic cheerleader for Block & Flow.
We worked remotely, from Indonesia, London and New York. It was a team effort and we learnt a lot together.
Design Sprint - Creating a magical experience
Lets now jump into what proved to be a breakthrough for us and take the reader through how it happened.
The reader will soon see that I am a big fan of Design Sprints and I hope to encourage people to either try their first one or to do more of them. If you’ve never heard of Design Sprints, you can learn more here or read the book.
We adapted the Design Sprint Process
As you will see, we adapted it as we saw fit and experimented. A difference is that because of the choices that we made, the Design Sprint took longer than five days.
Our process followed the five stages of the Design Sprint methodology but we made changes to the details. Understand, converge, diverge, and evaluate were not changed. The change we made is that prototype became implementation. We found implementation better reflected that we used different options depending on the Design Sprint, and not solely a prototype.
The five stages are foundationally important. My opinion is that the discipline of going through these five stages creates better product. Although the details or execuction of each stage may vary.
If you are new to Design Sprints, my suggestion is that it is more important to go through the five stages, than how long it takes. It might take you longer than five days to go through them. With more practice and by adding missing skillsets, you will get quicker. You can also run one with a few people as you figure them out.
Stage 1 — Understanding
This Design Sprint would focus on the ‘small successes’ of Block & Flow. We raised the criteria in line with our aim to make an app that people love. The challenge became ‘how might a small success be a magical experience?’
The small success for us is when a person finishes their time spent on something. We wanted someone to feel a sense of accomplishment when their block, a twenty-five minute countdown, finishes.
The scope could have been much larger, it could have been to design the iOS app. No, we wanted our focus to be tight, and to make a breakthrough for the essence of the app. The scope was to redesign the experience of a small success, and what happens after a small success.
As you can see from below, a fair description of the app at this stage would be awkward. The concept of building up blocks throughout your day seemed promising, but the design was weak and too complex.
The two of us had tried to improve the design and had been unsuccessful. We felt blocked because we lacked a strong design. Our plan was to try crowdsourcing the design. We used a service that we had never tried before, 99 Designs. We had no expectations, but had a good recommendation.
A clear and concise brief was written for the designers, and we researched how to run a successful design contest on 99 Designs. Our strategy was as follows; to use the top prize option, to make the scope deliberately small and encourage creativity, to be helpful and respond quickly to the designers, to contact the best designers on the platform and encourage them to take part.
Stage 2 and 3 - Diverge and Converge
The brief was posted to 99 Designs and the design contest started.
We looked through as many designers as we could. If we liked someone, I would write them a personal email, and using my best salesmanship, encourage them to take part in the design contest. One reply told me to ‘stop spamming’, whilst many of the replies appreciated my efforts. It became the start of a conversation with a designer as they worked on the design.
We were available throughout the design contest, responded promptly to any questions, and critiqued the designs. Our critiques would make up to three points, one strength, and two ideas for what to improve. The improvements might be feedback on what is weak in the design, or encouragement to create further variations on some aspect.
Many designs were explored, however there was only one that truly excited us. It came from a designer in Indonesia, who I had reached out to previously and joined the contest because of my email.
What did we like about the new design?
- At this time, a common design choice was a circular progress indicator. It was, is everywhere. We needed to stand out, not blend in. When thinking about differentiation, I always think of Seth Godin’s explanation, be a purple cow. This design was visually different to other apps.
- The new design simplified and reduced the previous design. In the previous design, the timeline moved from right to left. This felt complex. In the new design, the timer was reduced to a simple box, that filled up as the time progressed. This felt simple.
- When thinking about how someone feels as they use Block & Flow, we used words such as calm, in control, simple, a sense of progress and happy. The new design made good use of whitespace; the elements had great proportions. It was simple and elegant.
We were thrilled with the direction of the new design and were excited to see how it would be received.
Stage 4 - Implementation
We created an appropriate implementation relevant to what we were trying to learn. For this sprint, the goal is to create a wow experience, so we built a native code ‘happy path’ implementation. A happy path implementation handles the most likely scenarios, not all the scenarios. For this reason it is quicker to code than a full implementation.
Using native code meant the user could judge it as an iOS app. We added animations and other details that go into making a good experience. One of the team is an exceptional iOS developer so we could use his skills.
We had belief in the design and wanted to find out if our confidence was well placed. We wanted to learn if we could wow someone.
Stage 5 - Validation
In the past, I had always struggled with arranging user tests. Recruiting people for user tests seemed both expensive and difficult. We needed an easy way to do user tests, so that we would do them regularly. Enter remote user tests.
Before this Design Sprint, we had tried remote user tests and found the following advantages:
- They were quick to set up and run. We did not have to recruit user testers. Preparing the questions for the user test took around half a day. I would write a first draft, and a colleague and I would improve the test further. Often we were able to create the questions for a user test, run them, and evaluate the tests in one and a half days, and sometimes within a day.
- Everyone involved could easily watch and form opinions on the user tests. This meant many debates were later argued from the point of what someone observed in a user test. (I did offer the designers competing in the design contest the option to see previous user tests. It helped give me a signal for how serious they were.)
- We could easily target the people that we felt, and later knew, would use the app. If the user test went well, we asked the user tester if they would like to be a beta tester, and many did.
Five remote user tests was how we evaluated the design. Why 5 user tests? Research shows that you find 85% of usability issues from five user tests. Five is the sweatspot for value and learning. It is enough to see the patterns.
A user test would last up to fifteen minutes, and below are examples of questions that we asked.
- The first question would be vague as we wanted to see someone use the app for the first time. We would ask a tester to “Start using the app”. The point of this question was to essentially just look over their shoulder as they used our app.
- A follow up question would be to test what had stuck with them. We asked, “How would you describe this app to another person?” What we were looking for was clarity and elegance in what they would repeat to someone else. We were testing if they know why they would use the app, and what (if anything) it was good for.
- Further questions would clarify that they could complete particular key actions of the app. We would ask them to do something, so that we could see how well they were able to do it.
- Now that they had used the app, we wanted to see what else we could learn, that had not already been seen or said. The question would be something like this: ‘Is there anything else that you would like to show or tell us about?’ Typically the answers would be about what was missing, what they found difficult and what they liked.
- We then used the net promoter question as our metric for how good the app is at the point of the user test. The question is, ‘ using a 0–10 scale: How likely is it that you would recommend Block & Flow to a friend or colleague?’
- Lastly we would wrap up by explaining the app is not yet in the App store, and ask if they would like an invite to the pre-release version. We found many of our early testers through our user tests. When the app was later in the App store, this would change to a download option.
Did the Design Sprint work?
Goal of the Design Sprint
The goal for the sprint was to see ‘how might a small success be a magical experience?’ Critiquing the new design, we were excited by it and felt it had promise. We were optimistic that we had a breakthrough.
Results of the user tests
The old design had been through user tests. A fair appraisal to the reaction would be lacklustre. The net promoter scores had been 2, 4, 5, 6 and 6. We wanted to hit 9s and 10s.
The new design was obviously better. This time the net promoter score was 4, 7, 7, 8 and 9. Whilst the scores had improved, what really shone through was that four out of the five testers had a real enthusiasm for the design, what lost us marks were usability issues or features that were missing. Three of the testers even gave their details so they could join our beta programme.
The user tests showed that we were heading in a promising direction. They showed us what was weak in the app and made it easy to see what to fix or improve. The requested features matched our own thougths.
If the design had tested poorly at this stage, this would have been an important learning. We would have asked ourselves the reason it failed. Some possibilities might be that the experiment was poor and compromised, or people just don’t care about what you are doing. It is better to find out where you are going wrong and then you can do something about it.
Finding superpowers and an excellent designer
We had done Design Sprints and user testing previously. They had proved themselves to us. However this had been a euphoric Design Sprint. We had the feeling of discovering superpowers.
Design Sprints allow you to access solutions that you are unlikely to find when working as individuals. The process includes many excellent techniques. For example, you create a volume of ideas. I believe that you need to generate many ideas in order to get to a good idea. You are also forced to take action and to make decisions. This means you do make progress and move forward. The five stages also provide a discipline and rigour because you start with a thesis, create the experiment, and then learn. This encouraged a learning mindset throughout the team.
The 99 Designs Design Contest was a great service. We were stuck on design, and lacked the skills within the team to get us out of the mud. I like the way that the contest was structured. A volume of designs are generated, which should result in one or more of the designs being strong. Ultimately, we received a design that we and the people that use Block & Flow love. As an equally strong plus, we also found a talented freelance designer to work with. We finished up with a great design and a great designer.
From speaking to many entrepreneurs, it is common for some skill set to be lacking in a team. A potential solution, is to find a freelance service, and use them in an appropriate way. Trying someone out before you work with them further is a good way to know if they can deliver what you need. It can also help you move forward when a lack of a skill is slowing you down.
User tests are definitely a big eye opener. It is like shining a torch into the darkness. Suddenly you can see if people are doing what you expect them to do and also where they are struggling. Then you fix the issues and try again. Five user tests is such a sweatspot for what you learn and for the time it takes. This is a very powerful iteration cycle that does take you far very quickly.
Over the course of time we did many user tests. Block & Flow is a business to consumer app. A takeaway for me is that consumer’s expectations for software is extremely high. To clarify this, take what you have in your mind as high, and then go much higher. The reality versus what I thought surprised me.
In a short time we had come a long way
It took us three weeks from start to finish. At the end of it we ended up with a promising design, a talented freelance designer, a list of suggestions for how to improve the app based on people using the app, two people added to our beta and the confidence that we could make big steps forward quickly.
What happened after?
Filled with enthusiasm, we wanted to do more Design Sprints and more user tests.
Our Cadence
A Design Sprint would typically take us two weeks or less. The reason was that we favoured a ‘happy path’ implementation, which took more work than a one day prototype. After a successful evaluation stage, we would improve the ‘happy path’ implementation and take it to production level.
We tried doing two Design Sprints a month but it was too much. We slowed down to one Design Sprint every three weeks.
This is how the three weeks would breakdown:
- Week 1 — Design Sprint understanding, diverge, converge and start implementation
- Week 2 — Design Sprint implementation and evaluation
- Week 3 — Fix what we learnt in the evaluation and improve the ‘happy path’ implementation
- Repeat
During the evaluation stage of the next Design Sprint, alongside the new experiment, we would evaluate the fixes from the previous Design Sprint.
When did we use a Design Sprint?
My preference is to do small pieces of work from start to finish. The advantages are that quality of work is higher, and regularly reaching a finish line is motivating. For this reason our Design Sprints were always for small, focussed and important work. For example, the app design was broken into several Design Sprints, and not just done in one.
For example, we would use a Design Sprint for an idea for a feature. When starting, we did not know what the feature would be like. We needed to work together to find the best solution, and to give us a higher chance of getting the feature right at the first time of trying. Design Sprints because of their process worked well for this.
The objective of a Design Sprint was also typically tied to a higher level company objective. For example, in a future case study, I will explain how we used a Design Sprint and other techniques to improve our retention. Design Sprints help you to focus on what you should and should not do. They set a direction for the team and build collective understanding for the next milestone that is trying to be achieved. This understanding of the direction would permeate to the work done outside of Design Sprints.
A Design Sprint also had the characteristic of helping us gain confidence in an area that we did not yet understand. For example, we might have an idea that we believed a user would find valuable. However, we did not know. We would then use the Design Sprint to explore the idea, and get us to the point where we knew whether it was valuable or not. It was a way to try ideas and de-risk them; before investing in them further.
When did we not use a Design Sprint?
We would not use a Design Sprint when something was obvious to us or that it was not the best way to get to the solution. For example, as we designed we would ask what is the most likely mental model that the user has in their head for completing this task. There are established mental models that we do have, an example would be forms or lists. If the mental model was a good and familiar one, we would use it.
Design Sprints take big steps, but there is a scrapiness about them. We would often polish the scrappiness through smaller or larger actions outside of a Design Sprint. These would be varied and could include improving a part of the design to coding parts of a feature not done in the ‘happy path’ implementation.
Beware of your cadence
We had settled into a cadence that prioritised doing Design Sprints. This meant that other important work would be written down and deferred. Our intention was to do them at a later date. Over the weeks, the inbox in our kanban board kept growing. These tasks would not be started until we decided to do them as part of releasing Block & Flow to the App Store. It had become a big amount of week, and would take us a month to complete. This month was a slog and drained us.
It is important to point out that there are other valuable techniques that work well with Design Sprints or offer something different. There is also other types of work that needs to be done. The challenge is to ensure all that is important keeps moving forward. In a future article, I will explain how Design Sprints fitted into our larger product process and also what our larger product process looks like.
Did we make an app people love?
The progress that the app had made was clear to us. We were proud of it.
We had worked hard but had we managed to create an app that people loved?
I found this message posted a month before the app went live on the App store. The submission to Apple mentioned is a TestFlight build, for our beta testers. During this time, the key metric for measuring our progress was our net promoter score. In a user test done shortly before going live on the App Store, we scored 10, 10, 9, 8 and 8. This was a great result.
(MIA’s or Most Important Action is one way that we stayed focussed and on time. I will explain them further in a future article.)
I am really grateful for someone who takes the time to write a review. I try to treat reviews with a healthy perspective. They help to show if we are going in a good direction. But I don’t want them to go to our heads. As a team we appraise ourselves on how we went about something, and not the result that we achieve.
Since these reviews, we have made the change so that you can change the time of a block. However, I still have lots of questions around this aspect, and plan to explore them further in a future Design Sprint.
Thank you for all the people that take the time to write a review or that send me helpful emails. I am very grateful.
Conclusion
This case study very much describes our earliest experiences with Design Sprints. During this time, the product improved hugely. As it worked so well, this is still a large part of how I like to build product today.
In the next article, I will share a Design Sprint that improves our retention. For the evaluation we split test multiple options.
In future articles I will explain our larger product process, how Design Sprints fit within it, some practicalities for making it productive and other ideas that might be helpful.
If you are interested in reading future articles, then be sure to follow me on Medium.
If you would like to try Block & Flow, then you can find it on the App store here
