Overview
Developing products is a very complex process. It always starts with an idea or vision. Our job at Appunite is to help you fulfill this vision. We use different techniques and one of them is called a Design Sprint. Originally designed by Google to validate an idea by testing a prototype of the service. Our goal for the Design Sprint, that I will show you today, was to validate our idea for the product to solve a particular problem - empower new & current users to engage more in an app.
The basic questions that we pose when we start designing a new product are:
- why do we do it?
- how is it exactly going to work?
- how do we know that we create features that matter?
- who is actually going to use our product?
These questions start the process and they are with us the whole time. They benefit the most if they are discussed together with the whole team that will be responsible for building your product - not just the project manager. In our teams, we work with you (as a client), project managers/product owners (that feel responsible for the overall outcome), designers, developers and QA engineers. All of them have their own unique perspective of products as they are responsible for different elements. Our meeting was attended by: Jakub - CEO of Visual Panda (Graphic Design Studio) who was running the meeting, graphic designer, project manager, android developer, iOS developer and a QA engineer.
When we engage all of them at the early stage, we save ourselves a lot of effort later on, as we don’t have to explain the whole vision. Everybody knows why we do it and how we do it.
The process
Our team met for 2 days and set up a few workshops. Unfortunately, the client was participating in our workshops only at the begging, highlighting an overall vision and challenges that they are facing. The process started with checking status of a current product (if you have one). In this case it was our main product, a social network app, with 120k active users monthly.
After 2 days of Design Sprint, we, as a team, did the following workshops:
Understanding the current status (statistics of the product right now)
After understanding where we are right now in terms of active users, their engagement, place where they spend most of the time in the app and user details like region or operating system, we will be able to decide on success metrics. By building a new product, we should understand what it means for the product to succeed. Building the success metrics can also be done using different approaches, Pirate Metrics are one of the possibilities, but this, of course, depends on what you need.
Understanding what the goal for the new product is.
Understanding the goal is a really important element. It all starts with a client that describes the world that they see and how they feel about users’ needs, what users do right now, what they need, how they communicate the needs and what the background is (social, political, environmental etc.). It’s all about trying to explain the perspective and knowledge of a client to the team that will work on the product. After about half an hour of intense discussion, we defined our goal for our product to be as in the example above. We want it to be used as a newer tool to increase engagement. This goal was a sentence that we had always written in capital letters, somewhere in our room. During workshops and brainstorming, the accumulation of ideas is so intense, that it is easy to get lost in the flow. Having a clear goals will always help us to get on track.
Defining what types of users we will have in our product and creating a flow of how these users are potentially going to use our product
Ok, so we started with a vision, but now it’s time to think (assume) who is actually going to use our product. It was not exactly like creating personas - the point of this workshop is not to define the “parameters” of a user, but think a little bit in more general terms, about how and why they will use our product. If we are able to clearly define the general “paths” of a user, it will be easier to define product flows. Defining who is going to be a user in our product will help us understand how they are going to use it, what their needs will be and what they will try to achieve. The ultimate goal for each of the user types that we have is to build interaction. It is important to notice, that our type of user is more like a hat, and one user can wear many hats or change them depending on a situation.
Listing many possible problems and needs of those users and dividing them into categories
As a follow-up from previous exercise, we need to dig deeper into needs and problems of particular user types. First, we try to anticipate needs and then we try to categorise them.
I would say that this is a typical brainstorming session, when we write on the post-it notes whatever comes to our minds, however tight or loosely it’s connected with our users. The goal here is to get a perspective on how your teammates look at those user types. The more diverse team you have, the better, as each teammate that comes from different background (development, marketing, QA, management etc) will have their own knowledge and perspective on our users.
For us, the categories were: Product, Content Consumption, Good UX, Advertising, Joining the platform, Making Money, Creating Content, Making Interactions.
As you can see, the categories itself are general and touch very typical elements of any product.
- Prioritising problems and needs (votes with blue and pink arrows) Priorities are the key. If you look at the photo above, you will notice blue and pink arrows. The team gathered to vote with blue arrows on whatever they feel is important while the client was given a “supervote”, that can influence next workshops. This workshop is correlated with understanding the goal and show if there is a difference in thinking between a client and a team.
In the example above, we pointed the following. 1. helping to create and publish content 6 2. increasing interactions between users 3 1 3. making it easier to find interesting spaces 3 4. making every space unique 1 5. helping users use app everyday 1 6. making spaces available publicly online 1
As you can see, we have a divergence between a client and a team - how did this happen? The client and a team looked at the problem in a slightly different way, while both we and our client understand the outcome (increase interaction), we targeted the cause - without a good way to create and publish the content in our product, it will be difficult to increase interaction. This became our main point of focus later on.
- Connecting priority problems and needs with user flows and deciding on success metrics
We marked the most important elements of flow: 1. making every space unique → in describing space 2. helping to create and publish content → in creates content 3. increasing interaction between users → in goal INTERACTION 4. making it easier to find interesting spaces → in browse spaces
The success metrics are: 1. Number of shared & added posts to product 2. Session time duration 3. Number of interactions on posts
This is just a simple activity to visually show where our needs connect to our users and the flows we created.
Deciding what element of the flow is the most important to test Together, we decided that creating content is the most important one. If a user is able to create an interesting content easily and with pleasure, that will make them more eager to stay and engage. This comes out directly from our prioritizing activity.
Researching other competitors’ products that are created around the decided flow element
Now, as we are beginning to approach the actual product design phase the fun begins,. The first step is always the same - we researched a few different apps on how they help users to create content. The exemplary apps were Tumblr, Talklife, Ted, Whisper, OLX, Vinted, Instagram, Facebook, Jodel, Tapatalk, Werble, Adobe Spark Post, Aminocreator. The findings and propositions were drawn on post-it notes and discussed by the team. Thanks to this workshop, we see what we like and what draws our attention.
Creating individual propositions how to design the flow element and deciding what elements of these propositions we love
This was one of the hardest parts of the workshop - a timebox activity (20 minutes) to prepare a prototype. This activity consisted of 5 steps.
1. Creating your initial proposition (we don’t stop here, see below) 2. Doing a “crazy 8’s” session 3. Drawing your final proposition 4. Discussing 5. Deciding on what’s cool and what’s not in each proposition.
The first thoughts are not always the best ones
Each member created their unique vision of the product. There were many different ideas so we voted with blue arrows on the ones that we liked the most to be used in our new flow. The process of constant iteration over ideas is the key of the design sprint.
- Merging propositions in a user flow that contains selected features
This is one of the most important and most difficult outcomes - we mapped the journey of a user from the start (seeing an advertised post on our mother-product), through elements like first opening of the app, login, creating content, publishing content and ending with our goal → sharing content. It’s the most difficult as we have to take all the perspectives, needs, flows and ideas and just put that into a single flow (it’s good if it fits 15 screens, as in the example). This flow adds a perspective to our proposed solution to think once more if this fits not only our product, but also our life.
Based on this flow, we created a simple prototype that will be tested with a client and users to help us decide if the flow we created meets real life needs and expectations and what we can learn from it.
Conclusions
The structure of the design sprint helped us to narrow it down from a very broad context of the product to a testable element that is clearly defined and has its position in our flow.
The next step is not to start development, but to learn if our thinking is correct. To test our assumptions and hypothesis. To get data on the tests.
The way we were following the steps of the design sprint encouraged discussion on many levels of the product and helped us to dive deep into the problem. We had to switch our thinking to “how do we know if we do the right thing?”. The learning process and iterations are the key. When you acknowledge that there are things you don’t know and you look for a way to find out if you are right or wrong, when you learn from it, that’s where the innovations happen.
That’s how best products are born. If you'd like to talk about your product, let us know.
