Site mapping and user flowing
For the past few weeks, we’ve developed our redefined solution idea. We decided not to focus on futuristic technology or hardware too much and rather design a system or service that can be implemented on different technologies in the future. As we buried the idea of projecting an interface on the user’s skin (for example for the obvious reason of what if you wear a long-sleeve shirt?!), we have moved away from thinking about the possible wrist band and design the prototype to look like a mobile application for now. Using the mobile application interface makes it easier for the users to experience the service that we have in mind. Perhaps, in ten years the smart watches are stand-alone devices that can use the service and collect data at the same time.
We started the design process of the system by creating a site map. After going back and forth with how the system should work and look like, we settled on, in our opinion, quite logical and clear solution (although the users will be the final judges of that). Below there’s a screenshot of the sitemap. Although it’s very clear to us, it might not be that clear to you, so I shall explain it a little bit. The system doesn’t have a separate home screen, but the user is directed on the Partner page where they can see their current status, which is the contextual product of their previous training sessions and the data collected. The current status could be recovery/rest day, need to run, running or need to recover.
The idea is that the user can go on the application every day to see what they’re supposed to do on that day. Also, the Partner page allows users to interact with Polar Partner. They can either ask them tips and Polar Partner responses in a concrete manner using the user’s data or they can, for example, ask how they should recover or train on that specific day. Polar Partner always gives suggestions, for example, if the user should take a recovery day and do foam rolling or stretching, or if they should go for a 5k. However, user has always freedom to deny the suggestion and train freely, as well. The other pages of the application are recover, train and my profile that shows the data history of the user. On the recovery page, the user can have an automated recovery routine session right after the training session or later when it’s suitable for them. The automated recovery routine is created based on the latest training data. The user also has an option of having a general recovery session where they can choose the activities themselves.
When it’s time for training, users have several options to follow. They can either do a free form training session where they can choose the form of training and duration themselves. The users can also follow the current status’s suggestion and do a recommended training session (for example that 5k), or they can ask Polar Partner what they should do that day. After the training session, the user has an option to move on to an automated recovery routine or do it later. I know, this might sound a lot, but I promise it all makes sense when I’ll explain the user flows we’ve created. But first, you can eye on the site map in more detail to get the idea.
Based on the site map, we created four different user flows that we’re going to design on the prototype, as well. We concentrate on the user tasks of getting information on how to recover, starting the training, finishing the training and getting tips from the Partner.
User task 1. Get information on how to recover
The user flow shows that the user has few options to get information on how to recover. Firstly, they enter the application’s Partner page where they can see their current status. If the current status is “recovery”, the user knows that it’s a recovery day and no need to train. To know how to recover, the user can tap the current status and is directed to the automated recovery routine to start a recovery session with pre-defined activities (based on the data). How easy is this? Another easy way of doing it is to ask Polar Partner. That’s what it’s for after all! The user can ask what kind of recovery they should do, and Polar Partner provides suggestions. Then the user can either confirm the suggestion and an automated recovery routine is started, or deny it and the user can come back to it later. But because we believe in the user freedom, we also have a third option of general recovery routine where the user can select activities and start a session whenever.
User task 2. Start the training
The user can always go and check their current status and know whether they should be sweating their arses off that day or hitting the snooze button. When it’s time for a sweat sesh, the current status would show “need to run”. When the user taps the current status, they’ll see what kind of running session they should be having, and they can start the session. Again, the user can also ask this from Polar Partner and get suggestions, or they can have a free form training session and do what they like.
User task 3. Finish the training
When it’s time to finish up the training session and the user has done their cool down, Polar Partner asks for a confirmation of a recovery session. If the user wants to do the recovery routine right after the training, they’re directed to the automated recovery routine that shows recovery activities that have been optimised for them based on their training session. During the automated recovery routine, the user is first shown an introduction of the total time duration, overall routine activities and the benefits of the recovery routine. The user does recovery activities for a certain time and is guided to take rest in between. After the routine is finished, Polar Partner recommends the user to drink some water and rest. If the user is busy right after the training session or otherwise doesn’t feel like doing the recovery routine right away, they can deny the confirmation and, if they wish, get a reminder later.
User task 4. Get tips from the Partner
If the user has any questions, they can always turn to Polar Partner. For example, if they wish to know how they can run better, Polar Partner will, with the help of the user’s data, give tips for running better. In this case, the user goes to the Partner page and asks their question from Polar Partner. Polar Partner asks some specifying questions and based on the responses gives tips. If the user is happy with the response, they can confirm, when Polar Partner gives an opportunity to ask something else. If the user isn’t content, Polar Partner asks more questions that the user must respond to until the user is happy.
We’ve now reached the end of this seventh blog post. With the help of the site map and the user flows we’ve started to create wireframes and eventually a prototype of Polar Partner. Tune in to the next post when we discuss the design process.
