Keane Riley
Cloudability Mobile Design
Summary
I designed a mobile version of the Cloudability web application. After some research (competitive analysis), I sketched out my ideas before turning them into a paper prototype. From there, I took those designs and translated them into a low fidelity digital prototype in Figma.
Skills Exercised:
-
Competitive Analysis
-
Sketching
-
Paper Prototyping
-
Figma
Research
The original scope of features I wanted to design mobile versions of were Dashboards, Anomalies, and Rightsizing. However, after light researching I decided to focus on Anomalies first.
I began my research by doing a quick competitive analysis of two other data visualization applications: Tableau Mobile and Power BI Mobile. The main trend I noticed between the two was the use of a desktop editor to create the mobile layout. Neither of these titans of industry had found it beneficial to allow users to actually manipulate raw data and create new visualizations in their mobile application. Because I wanted to first get Cloudability up to speed on basic mobile capabilities I made the decision to forego creating this type of interaction in my designs...for now.
The next step was to create a persona and use that to define the requirements of the app. While I did not do any primary research, I have multiple conversations every week with primary users of Cloudability in my current role. I drew on my customer interactions to create a basic persona of a intermediate user that is part of the Cloud Operations team, who uses Cloudability to help identify areas of their companies Cloud Usage that could be financially optimized.
Taking what I learned from the competitive analysis, and combining that with my persona I extrapolated requirements, and decided to start my design with the Anomaly Detection capability.
Sketches
I started ideating by sketching out what I wanted the application to look like. I started with a the basic list view of anomalies, thinking that would translate the easiest. I wanted to avoid requiring the user to scroll in two directions to read the table so my first task was to decide what anomaly information would be the most pertinent. I believe the date and account would be the most helpful to quickly determine if an anomaly needed deeper analysis.
Next, I tackled the detail page for an anomaly. This was my biggest challenge as I needed to fit quite a bit of information on this page. My goal was to fit everything on a single page so that minimal scrolling would be necessary. I believe having both the context (tags, other metadata) and the graph visible together reduces the distraction of scrolling and hiding part of the data's story.
Ultimately, I could not avoid scrolling entirely; I applied a swim lane pattern to the "Tags" and "Business Dimensions" sections. I thought of this after applying the same pattern in a second iteration of designing the anomaly list as cards with graph previews. While this version of the list view did not make my final design, the exercise proved fruitful for inspiring a solution for another problem.
With the to main pages of Anomalies sketched, I turned my focus to navigation and a header for date range and view selection (views are a way to set pre-defined filters on the entire platform). I gravitated towards a standard drawer style menu for navigation elements, but sketched out a static navigation bar across the bottom of the screen to feel out another option. Because there are so many areas I felt that the drawer navigation offered a better way to view a list of areas. This pattern is also used in the web app which will feel familiar to users and is one less piece they need to relearn.
The final interaction I sketched was setting up a notification for an anomaly alert. The first sketch shows my attempt to fit the options for the notification in the right drawer where I placed the notifications. I realized that this would be too small for comfortable use so I expanded to using an overlay on the whole screen.
Paper Prototype
After I finished sketching out my ideas and selecting the designs I wanted to move forward with, I began creating paper prototypes. A quick internet search provided me with some great phone templates and I opted for one with a grid to help keep my prototype clean.
When I printed out the templates, I printed them roughly the size of a real phone so that I could approximate how much of my initial sketches could comfortably fit on the screen and allow my thumbs to accurately select items on the screen. As I drew out the paper prototype screens, I realized I needed to take into consideration the status bar across the top, which compressed the space I had to work with more. You can see the screens I created before considering this (oops!).
Digital Prototype
When I was satisfied with my paper prototype, I started the process of turning it digital. Normally, I would have liked to do some usability testing with the paper prototype, but the reality of Covid-19 necessitated that I forego this step.
When evaluating my options for creating a digital prototype, I settled on Figma. It had been a number of years since I last used Figma and I took some time to get reacquainted with its workflow. However, I acclimated fairly quickly and started building.
I first looked for some mobile templates to help keep the prototype in perspective. After finding one, I next looked for a some wireframing templates and found a great one that had a wide array of icons, buttons, etc ready to drag into my design. This allowed me to focus more on the the user interactions while keeping a cohesive feeling between elements.
After all the pages were created I used Figma's prototyping feature to create the interactions between the elements. While most of the connections required a basic switch between screens, I did attempt to create an expand/collapse interaction when selecting an Anomaly from the Anomaly List which required some extra work. The end result is not perfect, but I feel for an initial prototype it imparts the basic feeling I aimed for.
Usability Testing
I created a Usability Test to gather feedback on using my prototype. There were three main processes I wanted to test:
-
Accessing the Anomaly Details
-
Closing the Anomaly Details
-
Creating an Anomaly Notification
Each test had a defined success criteria:
-
User clicks on the "Aug 12" anomaly to expand the Details page
-
User clicks on the “Aug 12” table line to collapse the Anomaly List
-
Alternative success: user uses back button
-
-
User clicks on the “Mail” icon, applies the “Production” view, and clicks the green check mark to save the new notification.
Findings
Accessing the Anomaly Details
No users succeeded on their first click. Users were able to get to the details page after a few moments of exploration. One user attempted to click on the Calendar first, explaining that they wanted to select the proper timeframe since the dates in the prototype read "2020" while testing ocurred in 2021.
Closing the Anomaly Details
All users succeeded using the Alternative criteria, using the "Back" button. However, when asked to identify another possible way to return to the Anomaly List, all users immedialtey identified the main success criteria. When asked why they thought to click the "Aug 12" line again, they pointed to the expansion interaction implying existence of a collapse capability
Creating an Anomaly Notification
This task had the most failure which I believe is in part due to using the word "alert" in my script. Users wanted to select the "Alerts" option in the right drawer which was my stand-in for the PagerDuty alert that can be set up in the desktop verison of Cloudability. Once users were guided to use the "Mail" option they were able to successfully set up an email notification for Anomalies.