STEP 1
User Research
User research was the foundation of our project, informing many of our decisions in the projects to come. To gather the information we needed, we interviewed four diabetics. Within this group there was representation from type 1, type 2, and gestational diabetes. These interviews were semi structured, allowing for flexibility to follow interesting topics while also giving each interview a common core. Once all of the interviews were conducted, the information was analysed to pull common themes from all of the participants.
Through this step we were able to create our problem space, which allowed us to find problems to solve. Without this, our group would not have begun to understand the issues our users face, which in turn gave us avenues to pursue for a solution.
As our very first step of research, our user interviews were what changed our curiosity about diabetics into interest. Fueled by this interest, as well as our newly acquired data, we moved forward with further projects that would crystallize our perceptions of our users. Personas were born out of our observations, giving us a tool that concisely represented our users wants, needs, and demographics.
Through this research, we found that important issues were not from inability to administer medication, or appointment handling, but rather difficulties with maintaining a normal life.
STEP 2
Personas
With our personas, we built on the information that our user research gave us so that it was in a format that was both easily understandable and easily presentable. To do this we took the transcripts from our interviews and pulled commonalities from them, coding them into more general categories. Once that was completed, we assigned these coded items to characters we created, making a fleshed out person with goals, complaints, and more. Placing all of that information into a frame that looked professional, we completed the personas.
These personas would go on to act as the touchstone for our future projects. By going through so much effort compiling our research into the form of a person, we created something that was easily understandable. This is useful not only as a way for us to form a clearer picture of of our users, but also a a method of explaining our users to stakeholders outside of our group. Not only that, but personas can be expanded on further by creating a User Journey map, which allows for a greater understanding of the users’ emotions.
We used affinity diagramming to group together traits from our user research.
STEP 3
User Journey Map
A user journey map is the natural progression from personas. To create one, you take a persona put it through a scenario that represents the problem space. From there, you map out the emotions and thoughts that a user fitting that persona would feel, capturing them through specific prompts in the scenario. To be fair this makes it more of an extension of a persona rather than its own project, but the information we got from it makes it worth separate consideration.
While it may seem like making up emotions for a fake person in a hypothetical situation has no place in fact based research and design, the real takeaway from journey maps is the process. Going through a scenario and asking questions through the view of the user, it allows for far more empathy for the issues that users go through. To come up with what someone’s emotions are moment to moment requires contemplating each one, and through that intimate understanding of emotions priorities can be given to different pain points. Using those priorities, the true issues can be discerned, which in turn become the project’s requirements for success.
STEP 4
Design Requirements
Creating our design requirements was proof that our research phase was over. We took everything we had learned from our user research and analysis, turning it into goals for our product. This led to a checklist of everything that we wanted our product to have. This in turn was broken down further into components of data and tasks needed for each of the requirements. Using this breakdown allowed us to set out specific tasks to complete, paving the way to a cohesive product. With these design requirements, we had taken the first step in creating our product.
This made it a key step in our design, as every step in our design built on those that came before it. Our design requirements became not only our goals for success, but also our our plan for how to move forward. By splitting our requirements into discrete chunks, we were able to take a more system design approach to our product. This gave us a better grasp of how our design needed to integrate our inputs and outputs, along with giving us a better sense of exactly how they were going to be completed. With a sense what to do and how to do it, we moved forward into exploring these options. Our four goals were:
-
Keep track of nutritional values in relation to blood glucose levels
-
Conveniently allow users to access and respond to their blood glucose levels
-
Unobtrusively monitoring blood glucose level in users
-
Alert users to anomalous blood glucose level.
step 5
storyboards
Producing a storyboard offered a range of ideas for our product usage based on the design requirements. Each member focused on a specific design requirement, recognizing pain points from our personas about maintaining diabetes and brainstorming how our product can offer a solution. Our team then visualized the scenario through sketches and photographs to create a storyboard addressing the design requirement.
Through creative solutions ranging from predictive blood glucose levels based on nutritional intake to data visualization of blood glucose levels, our team was able to explore different levels of integration of our product into our users’ lives. This process helped our team from having general product design requirements to specific key processes that would be the main function of our product.
STEP 6
Information Architecture
Thanks to the creative exploration from storyboards and clear design requirements, our team was able to determine concrete concepts of what our product offered. Naturally, our team began to create an information architecture that structured our product into scalable information flow for our users. This led to three main specific categories of structure: blood glucose levels, exercise input, and nutritional intake.
The architecture visually highlighted major processes that were key functions of our product while also showing lower level details of the product. Due to the large scale of the product and the complexity of managing diabetes, the information architecture was continually refined to improve user flow in each hierarchy of processes.
Additionally, establishing the information architecture allowed our team to focus on key function and pathways for paper prototyping and evaluations. Throughout the paper prototype and the evaluation process, our team would iterate back to the information architecture to improve user experience and structure.
STEP 7
PAPER prototypes
Based on our information architecture, our team was able to sketch key screens that highlighted the main functionalities of our product. The prototype of the screens were sketched on paper for easier access and minimal cost. The paper prototypes were then utilized in user evaluations of our product, substituting the prototypes as an interactive screen. Additionally, the prototypes also reflected of visual design choices that would become our reference for wireframing and high fidelity mockups.
The prototype included screens that are part of a key path scenario that our users would frequently undergo as well as additional sketches for home screens of our three specific categories. The prototypes were designed and organized based on their hierarchical level based on the information architecture.
STEP 8
Quick evaluation findings
Through utilizing the paper prototypes, our team asked users to stimulate food and exercise input while also setting up personal goals to based on user needs. The usability testing and evaluation offered direct feedback from our users about the current model of prototype as well as our design choices.
Task 1: Accessing BGL data
In understanding that the main cornerstone of the product is to access blood glucose readings, our users were asked to toggle different views of the blood glucose level graph.
Task 2: Meal Input
In all three types of diabetes, nutritional intake values are fundamental to regulating blood glucose levels. The task involved having the users input a consumed meal, which led to heavy dependence on user input. This task also mimicked exercise input allowing our team to extrapolate our findings to other user input portion of the app.
Task 3: Goal Editing
The users set target ranges for food intake and exercise goals to monitor their progress during the day. These goals serve as a reference to help maintain the users’ current state of diabetes.
The feedback from our users was able to be separated into three main categories: layout, symbols, and the goals page.
LAYOUT
Our users had difficulty in information presentation as well as input system for food/exercise values. Our team address the concerns through replacing the main navigation bar as well as allowing text input rather than scroll bars for input values.
SYMBOLS
​
Our users voiced their confusion with symbols or lack thereof. Through rearranging visual elements and streamlining the user flow, we were able to address the concerns with buttons.
GOALS
The goals page had offered three types of exercises. However, our users had highlighted our assumption of users’ understanding of the different. To remedy the issue, we included a popup to explain the exercise types.
The main concern from the usability testing was the complex user flow that allowed the users to take multiple pathways to achieve the users’ purpose. The evaluation became a pivot point that redirected our attention to the information architecture and user flow, pushing our team to simplify the architecture to improve user experience. The feedback from the evaluations helped to finalize visual design choices made for the annotated wireframes as well as clear justification for certain user experience design choices.
Step 9
Annotated Wireframes
By the time we had reached our annotated wireframes, we were on the final stretch for our project. Having just gotten feedback on our design from our testing, we began the process of editing our paper prototypes into a finalized version. This involved not only adding the changes our testing suggested, but also standardizing our pages so that they were properly spaced and professionally designed. Once that was complete, we annotated each page with the functionalities that were not not clear from visuals alone. Although it took quite a bit of effort, the end results were worth it.
Creating a proper wireframe is important for a number of reasons. First and foremost, it is a model of the entire product, not just key paths or other pages pulled from the whole. With a complete model it is possible to see the full extent of information flow, and any errors that may reside within it. Another important reason, however, is the proper layout of all the items on the pages. It is only by standardizing the layout to fit a proper grid that a prototype begins to become a final product. There is, however, one final step to get that far.
The Result
High Fidelity PRototype
After finalizing the annotated wireframes, our team created high-fidelity mockups of three main screens. Creating high-fidelity mockups meant high level of details including colorization, context, and iconography. In culmination with the feedback from our annotated wireframe and usability testing, the high-fidelity mockups represented the final touches to product’s visual design.
In understanding that each visual component was designed with our users’ in mind and purposefully chosen, the high-fidelity mockup brought together the our vision with the research to create a visual product for our users. Although in the industry the process would continue to a full functioning prototype, for our team, this would be the final presentation of the product.
Moving Forward
A Brief Reflection
Although the project only lasted 10 weeks, for our team this project quickly gave us a purpose to design for. From the beginning of user research to scaling the information architecture to finalizing the details in our wireframes, our team has chosen every design element to benefit the user. While still far off from being a product that could sit in an app store, it's on its way to making something that can be truly useful.
Originally, the project had multiple components from wearables, mobile apps, to continuous glucose monitors. However, as the project progressed, our team began to focus on the SweetLife app to hone in on our users’ needs, as data isn’t useful unless it is collated and displayed properly. Perhaps if we had a longer duration, it would be possible to expand the SweetLife app into some that had greater integration between devices. Furthermore, it would have been beneficial to gain feedback from a dietitian or a medical consultant to fully address the needs of the diabetic from a medical standpoint, both in BGL regulation as well as the related diet and exercise requirements. Finally, we would drastically expand our user testing pool so that it had representation with older individuals, less educated individuals, and those who had little to no knowledge of diabetes despite having it as a condition.
As for what we learned from all of this, it was more than we could have ever imagined. Naturally, we learned the process of a full iteration of product design, but within there were many unexpected nuances. Making fake people is really useful to understand real ones, design requirements can act as plans as well as goals, grids are only as useful as they are flexible; all of these were small surprises we encountered as we pursued our goals. Beyond the academics, we learned quite a bit about diabetes and its care as well. There is a lot of information out there, and some of it is created by diabetics rather than doctors, making an interesting look at what users truly want out of services.
At the end of the day, diabetes affects a large portion of our community. We chose it for the challenge that the community entails as much as for it being something that we could tackle in 10 weeks. Having a passion for making our product was what made us so effective at working together, and helped us make a product we were proud of. We made lots of mistakes, learned from each of them, and tried again. Given all of this, we’re ready for the next iteration, if there ever comes a time for one.