At an early-stage startup, Saturn, among many design tasks across mobile and web, I led the overhaul of Tasks on Saturn’s mobile app as well as the integration of Tasks into Saturn’s mobile Home view.
Saturn, an early-stage startup with 4 designers, is creating a platform for high school students with hyperdense social activity and equally ubiquitous utility capabilities.
In September 2020, I joined the design team, eager to find places where I could make the most impact. While I put out fires across both the mobile and web applications, perhaps the most influential work I conducted was refining and extending the utilitarian features of Saturn.
Saturn allows students to manage both school work and personal to-do’s, called simply "Tasks". However, it was clear that students weren’t taking advantage of this feature when I joined.
Auditing analogous UI, auditing the current UI, defining user needs, mocking up solutions, iterating based on feedback over and over.
I decided that my first step should be to pursue an in-depth audit of to-do/task-management apps that were solving similar user problems.
There were several trends that were readily apparent.
Most apps audited utilized an extremely lightweight modal view to create a task. In some cases, (i.e., Todoist), the modal view would persist after creating a task, thus prompting further task creation.
While many tasks could have extended functionality (i.e., sub-tasks, notes, attachments), the actual UI of tasks is minimal (and heavily icon-reliant), leading to maximized vertical information density on the tasks view.
Microsoft To Do and Todoist featured multiple lists depending on the use case. For example, users can only view their tasks without due dates in the "Inbox" list (Todoist) as well as the "Tasks" list (Microsoft), and can enter a specific view for solely the tasks that they're doing today ("Today" and "My Day").
I then played with our current tasks view on Saturn, noting observations and potential pain-points in the user experience.
A larger task UI and due-date headers occupies vertical space inefficiently, only ~3 tasks fit on a screen as opposed to 5-10 in the audited apps.
Clicking "+ New Task" opens up full-screen modal view – feels very heavy weight compared to audited task-creation flows.
Tasks are organized vertically with no-due-date on top, followed chronologically by due-date.
The only top-level interactions for tasks are hidden, while users need to either click once to mark a task as completed or click twice to edit and delete a task.
At this point, to bring a human-centered perspective into my design phhase, I sought to empathize with users who have an opportunity to use Saturn tasks but drop engagement eventually.
Sarah is a freshman who is pretty nervous about starting school and having to manage all of her homework and to-do's.
Opens Saturn, confused by what she should use Saturn Tasks for or why she would want to use it anyway.
Begins adding homework that was assigned the past week, but gets exhausted and even more stressed by doing so.
When she does finish tasks, she sometimes avoids marking tasks as completed because it takes too long.
Unmanaged tasks quickly build up, overwhelming Sarah, so she drops using Saturn tasks altogether.
Alex is a straight A student who finishes his homework early and keeps a never-ending list of personal to-do's.
Open-minded, Alex makes a ton of tasks, some personal without due dates, others homework with due dates.
Wishes there was more functionality for each task to elaborate on task details.
Whenever he opens the Saturn tasks view, has to scroll through 20+ tasks without due dates to see what is due next.
Decides to drop Saturn Tasks in favor of personal planner.
The personas allowed me to understand the concrete user needs that Saturn Tasks is currently not meeting for many of our users, regardless of their approach to homework and personal to-do's.
...need simpler methods to create/manage tasks because the process currently compounds the stress they feel about tasks.
...need a more empowering organization and functionality for their tasks because they thrive off of prioritization and elaboration.
Introducing Shared Tasks would streamline the task-creation process for students who aren't creating tasks themselves. I worked with another designer to spec the shared tasks UI and functionality.
Separating unscheduled tasks out of the default Tasks view allows the user to immediately see highest-priority tasks and thus have a clear mental model of what to work on next.
The creation modal view now only takes up half the screen, offering a subtle entry point to create a task for users who need less friction to create a task.
Upon creating a task, the modal view persists, thus prompting further task creation and eliciting increasing engagement.
Users can now quickly edit/deleting the task with one less click.
An engagement-feature, users can share a task elsewhere to classmates not on the app.
A small eng. cost, the description feature allows users like Type A Alex to personalize tasks further as needed.
Marking a task as completed is now explicitly prompted on the task UI, streamlining the task maintenance flow.
The new UI allows 6 tasks to fit on a screen compared to 3, reducing scrolling required.
The team appreciated the new simple creation flow so much that we decided to push the refinement immediately.
These changes, at a small engineering cost, would streamline our task views visually overall.
This thinking aligned with some conversations around the product team – the team agreed that it would solve the cold-start problem of users having no tasks.
Our design consultants from Snapchat worried that my new architecture was overly complicated, for users and for eng. How might I consolidate the 3 types of tasks (Scheduled, Unscheduled, Shared) to a simplifed view?
After several variations of a consolidated IA, I still wasn't happy with the results. Consulting with my teammates, I realized that I was overcomplicating things visually and from an interaction standpoint.
I utilized 2 accordions to streamline visuals while striking a balance between discoverability of shared/no-due-date tasks while still surfacing, at the top-level, the highest priority tasks that are due soonest.
I also took a step back, and began to ideate towards increasing task engagement via more orthogonal routes to the audit-and-improve design process I had been undertaking.
With no onboarding to tasks, users have no knowledge of the feature's value proposition and need to overcome substantial inertia to start creating and managing tasks.
At a small eng. cost, I was able to communicate value proposition and example use cases for tasks while also encouraging task usage via pre-created tasks themselves. These pre-created tasks also encourage engagement elsewhere across the app.
With the team's support for task onboarding, I decided to run with this "intra-feature" line of thinking.
Tasks live within the Tasks tab and nowhere else. Thus, users currently can use the app and never even think to use Tasks unless they've visited the Tasks tab. While this might not be too problematic, there's a clear opportunity to spur more task engagement by directing the user to Tasks from elsewhere in the app.
The home tab was an obvious choice as an entry point because, while the user is outside of class, it's a largely dormant tab. These mock-ups allowed top-level (i.e., visible as soon as the user opens the app) callouts to provoke relevant task engagement.
The team overall likened this idea to some of the discussions across the product team about rethinking our IA.
Reviewing the current UI, defining user goals for Home, iterating mockups individually, defining priorities with team, grayscale wireframing, higher-fidelity prototyping.
The Home tab currently serves as the students's one-stop-shop for their schedule. Upon opening the Saturn app, they can swipe the sheet up to view their entire schedule.
The home tab addresses 3 states depending on the use case (in-class, out-of-class, weekend). However, it is clear that this change in state isn't being leveraged to the fullest extent, leaving out-of class/weekend states rather dull and useless to the user.
Because I was focusing on an entirely new direction for Saturn Home, I knew, for the sake of productive design discussions and team alignment, the best place to start was to outline my proposed user goals for Saturn's Home tab. If the product team can't agree on my goals, then there's no point to showing them the screens that were designed to fulfill those goals in the first place.
Saturn, while having lofty ambitions as a hyperdense social product, can thank all of its current engagement to the utility features, specifically, the Schedule. Why not double-down on providing students with unique high school-specific utility to drive more growth that we can in the future leverage towards a more social direction?
I found a helpful working analogy in the planners that my classmates and I carried around with me throughout high school. These notebooks were our savior – they outlined our schedules for each day, and we would write down our homework for each class there as well.
I kept these insights top-of-mind as I devised user goals that made most sense for Saturn and our users.
Users use Home to...
Answer: what do I need to do?
Answer: what's coming up?
Distill mental model of immediate time horizon.
The design consultants from Snapchat, while agreeing with these goals, also stressed the importance of simplicity for users. In order to meet goal 3 in an elegant and efficient manner, we must not confuse or overwhelm users.
While defining the user goals crystallized the overall direction for Home, the manner in which these goals would be solved would depend heavily on the time-of-day. Whether a student is out-of-class or in-class, the two primary use-cases, Home needed to be solving their needs in a manner that makes sense for the time-of-day.
These screens breathed life into the currently static in-class state, prompting users to create a task (inspired by the spike in task-creation during class), or view class-members, or enter the class chat.
Subtle "Next class" and "Tomorrow's schedule" UI allows the user to quickly understand their upcoming schedule.
The screens, without a clear visual anchor, lead to overwhelm and complexity. How can we communicate priority elegantly and effectively?
A contrasting color arrangement and sense of z-axis seamlessly directs the user to top-level UI before the gaze down to the sheet.
While Tasks and Schedule could be accessed through the same view (Home tab), they resided on separate, mutually exclusive views altogether. What if we integrated the two into the same view?
By forcing Tasks into the same real estate as Schedule (and framing them as 2 different temporal views), we're corrupting/confusing the individual content of either area (“wait, so I can see Today’s schedule but also tasks without a due date?”, "where did my classes go now that I'm in the weekly view?", etc.).
My individual work had clearly shown that this overall direction for Home was where Saturn wanted to head. With my insights in hand, I began to work with team members to solidify our design thinking behind the final solution.
Building on-top of my user goals, our team wanted to dive a level deeper. How do we want users to FEEL from using the Home tab?
Home provides users with a sense of understanding over where they are and what they need to do.
Home reduces users' anxieties rather than creating them.
After using Home, users feel ready to take on their schedule and their to-do's.
Our team wanted 100% alignment on what our priorities were depending on each time-of-day use-case.
We brainstormed every possible (relevant) piece of information that we could show on the Home tab.
We then stack-ranked how important these pieces of information were to our users based on our user and emotional goals for Home. We tied this thinking to use-cases to reflect the dynamic behavior of Home as well.
This exercise illustrated how peeking information would keep things simple for the user by showing only the highest priority information given their situation (in-class or outside class) so as not to overwhelm, then drill-down to view further elaboration on that information. One example might be to only show the user's next class while allowing them to drill-down to their full schedule.
In the meantime, one of my teammates mocked up a wide variety of grayscaled wireframes.
From these, we could analyze each one, determining where the stack-ranked information would live, and to what degree this organization would meet our goals.
Two distinct sections for Schedule (pictured: "Calendar") and Tasks provided for the modularity (and thus, simplicity) that we were looking for.
The architecture also enabled the UI to "peek" high priority information which the user can then drill further into.
For UI inspiration, and as a pseudo mood-board, we brought in all of the previous Home designs that had been designed at Saturn.
Inspired by the visual directions of several card-inspired layouts, we incorporated our stack-ranked priorities into the grayscale wireframe to produce our higher-fidelity prototype!