large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

Published on <a href="https://blog.prototypr.io/paper-prototyping-d6917202fd89?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Pooja Trisha Ghelani 
<blockquote>Showing personal health data on smartphone</blockquote>
<h4>Research</h4>
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Is0XFVcQQ0yxIWlIoSHNtQ.jpeg">
In order to come up with a paired application that effectively enabled both the smartwatch and the smartphone to communicate I first researched the most common uses of smartwatches. I did this so that I knew I would be designing an application that would be useful.
You may also be wondering why I researched the most common uses of a smartwatch rather than a phone. I could have approached the problem either way, but I wanted the application to complement the use of a smartwatch specifically. And I wanted to give users information on their phone that may add on to information collected by the smartwatch, but wouldn’t necessarily be ideal to view on the small watch interface.
If I decided to focus on the smartphone then obviously the common uses include calling, texting and checking mail. The calling feature was not something that I wanted to implement, and the other two would be difficult tasks to accomplish on the smartwatch because of its small interface.
So getting back to the main uses of the smartwatch, research has shown that they are:
<ol>
<li>Checking “activity rings”</li>
<li>Checking the time</li>
<li>Checking notifications</li>
<li>Measuring heart rate</li>
<li>Making and receiving phone calls</li>
</ol>
Notice that two of the five of these are focused on something to do with physical activity. This was when I decided that I wanted my paired application to focus on something health related.
<h4>Design</h4>
I decided that the application would take in data that was health related, such as information about the steps they took, their diet (which they could keep track of by taking photos of their food), and cardio information. These features are commonly used on the smartwatch, but I thought having an application on a smartwatch that showed graphs and statistics about this data collected over time would be an effective way of showing this data to the smartwatch user.
For example, if a user turned on the cardio tracker on their smartwatch and wanted to check their heart rate over a week or the past month to see any trends they could check the app on their smartphone that would have taken the data from the smartwatch. Also if there was a certain goal set for a heart rate or amount to walk, the application on the phone will show how much progress the user has made towards that certain goal.
<h4>Prototypes</h4>
<img alt="" src="https://cdn-images-1.medium.com/max/784/1*oYxtl0J9THrFwLz1lvIVfA.png">
The prototypes I made went through the interaction of how a user could turn on the step counter on their smartwatch. When the user chooses to track their steps they open this application on the watch and turn on step count. There will be a small icon on the righthand corner showing this feature is on and recording their steps. Then this data automatically syncs with the health app on their smartphone. They could also enable tracking of these things on their smartphone, except things like heartbeat, which cannot be accurately tracked on a smartphone. However only one device could be tracking one thing at a time.
<img alt="" src="https://cdn-images-1.medium.com/max/485/1*JbCqUKS_o85DjJzxbjRJfA.png">
The prototype I made of the smartphone application shows going through an interaction of looking at the analytics for the step counter. When the user clicks on the analytics button they can choose to look at the step data for the past week, month, or year. When they click this they see a graph showing how much they walked on each given day. They are also shown a goal they may have inputted for how much they want to walk and how much they actually walked.
<h4>Analysis</h4>
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2Fobqa1_gjtaM%3Ffeature%3Doembed&amp;url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dobqa1_gjtaM&#038;image=https%3A%2F%2Fi.ytimg.com%2Fvi%2Fobqa1_gjtaM%2Fhqdefault.jpg&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=youtube" width="640" height="480" frameborder="0"><a href="https://medium.com/media/830cd696e5e9fcb99ed573ce6fe39f2d/href">https://medium.com/media/830cd696e5e9fcb99ed573ce6fe39f2d/href</a></iframe>
When going through the paper prototype, the flow went well. However, I had to first instruct the user that they had to go through the trying to turn the step counter on and they did not understand what I meant until they got to the second screen on the prototype. Even then the user was a little bit confused with which button they had to click because cardio and step counter seemed similar to them. The rest of the interaction with the smartwatch went smoothly.
When the user was interacting with the smartphone part of the prototype that’s when they got confused. I told them to find the analytics for their step count and they instead clicked on the step count button that would enable them to turn on the step counter. I then had to explain to them that the application could both track data as well as be used for analytics. After explaining this was the user able to effectively click on the analytics button and choose step count within that section.
Overall, I found three different problems with my design.
The app on the phone and its multipurpose use: Overall I found that having the app on the phone do both the analysis and tracking of data is confusing to the user. Either this should be more clear in the design, or the app should just be an analytics application.
Some wording was confusing: The participant got confused between the cardio and the step tracker. They thought the cardio button may include the step tracker or something along those lines. Overall, the information architecture should be more clearly specified and the wording shouldn’t be this similar for the different categories.
If the devices are connected there should be a way to prevent both trackers from being on at the same time. If the capability of being able to track the same data on both devices is left in the applications then there should be a way of preventing someone from turning on the step tracker on both the phone and the watch for example. This would create invalid and inaccurate data. The user pointed this out, and described that this problem led to their confusion about the functionality of the phone application.
Overall, I found paper prototyping to be an effective way of testing out ideas. Even though paper prototypes are very basic and low fidelity, they could show you some key problems your design might have which you could take into account before creating high fidelity wireframes on a design software.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d6917202fd89" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/paper-prototyping-d6917202fd89">Paper Prototyping</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Paper Prototyping

Paper Prototyping

Research

Top Stories