I wanted to design Symplist when I noticed a friend struggling to find a decent app that would effortlessly answer the question “yes” or “no”. Determined to come up with a solution, I started to craft an application that would ideally be really good at that one thing. What I found was that it wasn’t just her, there were others searching for the answer to that same question. Allow me to explain how I provided people with an easier way to accomplish more.
“Symplist provides increased productivity to busy and active consumers by providing a minimal and elegant user-friendly environment focused on quick functionality, giving them a sense of accomplishment.”
- Users spend more time setting parameters (calendars, times, filters, etc.) than completing tasks (average time per use was 15.59s) using alternate methods
- People are still using envelope, scrap paper, etc., to create to-dos
- Users need an easy way to add/remove items while engaged in a particular task
- More than 58% of people who answered are unsatisfied with their current task management tool(s)
- The learnability of how to use progressive web applications
- Database management when an update or change is detected
- Building a minimal working digital experience for users to keep track of tasks
- Flexible product structure that looks great regardless of device or operating system
9 participants took part in interviews that enabled me to learn and validate my assumptions that converted into personas. Some of this qualitative research was achieved guerrilla style, while others were held more formally to establish common frustrations and goals.
Based on the personas, storyboards were created to aid the types of situations this app would be used in. This allowed insight into interactions on how our audience needs to receive feedback in order to circumvent a poor experience both in the moment and while using the app.
I enjoy storyboards because they help fill in the gaps of my initial research. I can iterate on original ideas by visualizing these scenarios that conceptualize into wireframes and prototypes. An example of this would be sketching when the keyboard becomes visible.
Six participants took part in moderated usability sessions for three low fidelity prototypes. Each user walked through a series of tasks that was recorded and compiled to show their successes and failures. Afterwards, our volunteers verbalized their experiences, affording a clear understanding of trends that needed to be corrected.
- Shipped the closed beta version
- Users want to tap “add” rather than tapping “input” to add a list item
- Users had no way to cancel the input
- On mobile, users did not like how the button floated out of its original state when the keyboard was initiated View Prototype 1.0
- Version 2.0 was built on Google’s Material Design Lite front end template framework. It was discovered that users are much more familiar with this layout pattern, even faithful iPhone users
- Participants were interested in learning how to download the app since it wasn’t native or available within their carriers app stores
- No visual feedback when all actions are completed View Prototype 2.0
- Introduced new brand identity
- Out of the box, MDL menu navigation caused unnecessary confusion. Due to this, condensed navigation into a single menu
- Symplist shipped! View Prototype 3.0
After the 2nd design version, a survey was used to better understand how the application iconography would be understood. This provided great insight for such a small feature.
I faced a few challenges, one being I know nothing of databases. Conveniently, HTML5 provides a web API property that allows browsers to store data locally. While most of this went smoothly, it took me a solid week and help in StackOverflow to learn to update the lists properly after a modification.
Usability testing made it clear there needed to be a screen for visual feedback when the view was empty. This was accomplished by checking the number of items in the list — which would then hide or show a graphic based on the results of that conditional statement.
Feel free to view the source code publicly on GitHub.
In the end, I had to compromise several features that I simply couldn’t build in efforts to get a working product shipped. Categorizing tasks into specific lists, ability to rearrange/edit tasks and sharing your list with others are all things I am still figuring out. Not only in regards to development, but also designing scalable, usable and delightful experiences for future releases.
After just a few months Symplist had saved an average usage time of ~7.43s on a handful of downloads. I also managed a 200-300ms improvement on render time between versions 2 & 3. There’s more to do, but I am pleased with the results!
View a visual case study of Symplist on Bēhance or download it here.