AeriaList: A Digital Glossary of Skills
This past Fall, I took a 2-credit course at the University of Michigan in Digital Product Design. It was designed to be a crash course in designing solutions to real-world problems for students who are considering a career as professional designers. In this post, I’ll talk about one of my projects for this course—a mobile app called AeriaList—as well as the process by which I tackled a problem and designed a solution.
Identifying a Problem
Around three years ago, I started learning aerial silks. If you’re unfamiliar with aerial silks, it is a circus art performance you might have seen in Cirque du Soleil where artists perform aerial acrobatics while hanging from a fabric. Over the past few years, I have taken classes at 3 different studios across the U.S. At each studio, every instructor I’ve had has recommended that students bring notebooks to class to jot down notes on the steps involved in new skills they learn.
Personally, I have never kept an aerial silks journal. There were a few times where I typed some notes from class on my iPhone, but honestly, I barely looked back at them. The result is that I forget about skills that I do not practice frequently. One of my more experienced friends keeps a fairly worn journal of aerial silks skills, and she often brings it when we practice at Open Gym; however, choosing a skill to practice usually involves skimming each page of the journal until she comes across something interesting or until she finds a specific skill she has in mind. This is largely due to the lack of order that results from recording handwritten skills in a journal—even when you become more advanced at aerial silks, you may still learn beginner-level skills every once in awhile, resulting in a jumbled glossary of skills organized only by the order in which you learned them.
From this experience stems my problem statement:
Aerialists who are learning aerial silks want something to keep track of the steps involved in completing each skill they learn so they can easily recall how to perform complex moves that they’ve learned before.
I want to clarify that “aerialists who are learning aerial silks” could mean aerialists of any level — there are advanced aerialists who still take silks classes. Any aerialist who is still learning new skills is a potential user.
My Design Solution: AeriaList
I decided to tackle my problem statement by creating a user-populated digital glossary of aerial silks skills in the form of a mobile app called AeriaList. By keeping a digital glossary rather than a handwritten one, aerialists easily locate skills in an automatically-sorted list from the convenience of a device that we carry around wherever we go. Additionally, a mobile app would provide the option to add photos or videos to accompany notes.
You can view the final InVision prototype for AeriaList here.
It took iteration upon iteration of each screen in the app to arrive at the solution you see above. To shed light on some of the challenges I faced as I evaluated and re-evaluated how to design the best solution, I will walk through the steps I took to produce the layout of the app’s main glossary screen, from low-fidelity wireframes to a high-fidelity prototype. Note: I will not be discussing the intricacies of the updating the visual style, but rather focusing on my solution to the problem at hand. For the sake of brevity, I will also not be discussing iterations of other screens, the on-boarding process, or transitions between screens.
I began by delineating the typical use cases of a potential user of AeriaList: creating a new skill, locating a specific skill by scrolling through the glossary, viewing a skill, editing a skill, deleting a skill, and searching the entire glossary for a specific skill.
From these, I came up with four main features I believed necessary to include on the main glossary screen: (1) a view of a list of skills in the glossary; (2) navigation to the “Create New Skill” screen; (3) navigation to the details of a skill; and (4) a search bar. I, of course, wanted the list of skills to be sorted in some way as well so that users could easily search through their glossary in an organized way.
I drafted some wireframes of a main glossary screen that accounted for the four features I delineated. There is a button to create a new skill and one to search the glossary, as well as a list of skills that can be clicked on for more details. The glossary can be sorted by date added, alphabetically, or by skill level. Each skill has an associated image and skill level as input by the user.
Issues: Obviously, this is a very low-fidelity wireframe to build off of; there is a lot of room to improve. Analyzing at the layout at a high level, I realized that the “skill level” sort option would be the most useful based on my problem statement. My intention was to provide options for users to more easily search through their glossary, but I felt that I overcompensated for the problem. Organizing the glossary first and foremost by skill level would cut out unnecessary clutter without sacrificing usability.
Iterate, Iterate, Iterate
Based on the problems with my initial wireframes, I decided to make the high-level categories “Beginner,” “Intermediate,” and “Advanced.” Then, within each category, I wanted to add the option to sort by date and alphabetically to give users greater control over how they search through their glossary. After speaking more to my friend in Open Gym about her aerial silks notebook, I also realized that one of the benefits of her notebook over my current design was the ability to easily bookmark pages with skills she wanted to practice more or string together. As a result, I decided to toy with adding a “Favorites” feature.
Above are some initial sketches and wireframes I came up with with the problems from my first iteration in mind. I toyed with ideas on the display of each item in the glossary, trying out material design-style cards as well as completely flat list elements. I decided that card elements didn’t make sense for long lists of items without much valuable metadata to display on each card. Finally, I tested out an additional “Sort By” option as well as a the ability to “favorite” skills.
New Issues: While I greatly improved upon my initial wireframes, several new problems arose with my updated solution. Firstly, I found the “Sort By” option clunky for a mobile design. It was inspired by Google Drive’s design for sort options; however, Google expects users of Google Drive to hold hundreds — maybe thousands — of documents of all types. It is thus appropriate for users to have control over the sorting of their own Drive. In contrast, since each category of AeriaList would probably have a maximum of 15–20 skills for the average user, skills could be sorted alphabetically by default and users still would not have trouble finding skills in the glossary.
There were also problems with my solution for adding a “Favorites” page. Adding navigation to the page on the top of the screen removed space for search functionality. Additionally, the icon used to symbolize navigation to the “Favorites” page was the same as the icon used to perform the action of favoriting an item; this is unintuitive symbolism, and could be frustrating for users.
The Final Design
To address the problems I encountered with my previous solution, I decided to completely remove “Sort By” functionality, and sort items firstly by level and then alphabetically. Then, I decided to compile all levels of skills onto one page—similarly to how iPhone contacts are sorted alphabetically on a single page, with a header for each character in the alphabet to separate contacts into categories visually. This freed up space for navigation so that the top tabs could be used to navigate between the “Glossary” screen and the “Favorites” screen. Finally, I added back the “Search” button.
Overall, I believe I came up with an elegant solution to the problems aerialists face in keeping track of the skills they have learned in addition to the problems that I faced in designing iterations of AeriaList—but that’s not to say I came up with a perfect solution. If I had more time and more resources, I would have liked to investigate whether a “Favorites” screen was truly necessary. For what purpose would aerialists mainly use “Favorites” —for bookmarking skills they want to work on, skills they want to string together in a performance, skills they have learned recently, or something else? And could there be a superior feature more fitting for this purpose? Additionally, skills can sometimes be classified in categories such as “drops” (skills that involve free falling while still wrapped up in the fabric). Would aerialists find it useful to be able to sort skills by these categories, or is search functionality enough to account for this?
Product design is challenging. In some ways, the process of designing reminds me of writing an essay: similarly to how each sentence in an essay should be a unique and productive contribution to further the thesis statement, each design decision—however small—should advance the product as a solution to the problem statement in a meaningful way. For this reason, designers must constantly think from the perspective of the user and ask themselves, “Why?” Why is this feature necessary—how does it contribute to solving the user’s problem? Why is the feature symbolized in this way, or located in this area of the screen? What information is absolutely necessary for the user?
Going through the process of designing a digital product demonstrated just how much thought goes into the design of a single mobile app, and the extensive iteration that is required to turn an application into a product. As a student with a background in visual design and engineering, I finally learned how to design with intention rather than for aesthetic appeal or functionality.