Getting More Productive: My Design Process in Developing a Mobile App in Week One

The below is an analysis of my project for Week One of General Assembly’s UX Design Intensive.

Opening Screen for App Prototype


Our goal was to design a prototype for a mobile app to solve a particular pain point within the theme of productivity. It was necessary to illustrate our design process from ideation to prototype.


Sketchbook, Sharpie, Marvel, Quicktime, Keynote


One Week

Introduction to the Product

Rise is an app designed to ensure the completion of the most important items on the user’s to-do list. It is designed to only complete the tasks the user has for the day (i.e. today only). It uses several design concepts to optimize for this productivity:

  • Constraints — The app only allows the user to input up to three items for their to-do list. This forces prioritization of tasks from the get-go.
  • Motivation — The app allows the user to input one “reward” of their choice that they will gift to themselves upon successful completion of their task. This gives the user something to look forward to in completing their tasks.
  • Visual Simplicity — The list of tasks is large, clear, and concise, making it easy to check items off and verify progress.

Check out the prototype of the app here:

Anatomy a Task — Analysis of Productivity

In order to understand how to make a user more productive, it was important to breakdown the elements of productivity. With my peers, we brainstormed what elements went into determining the level of a user’s productivity. Factors included the following:

  • Motivation
  • Distractions
  • Procrastination
  • Focus
  • Prioritization
  • Execution

Out of the above, I decided to examine the element of execution. It was important to understand what determined a task to be completed. A to-do list could be perfectly prioritized, and the user incredibly focused, but even then a to-do list may not be completed. In order to better understand the user of this app, I had to understand why.

Breaking down ‘productivity’

Thus, I continued a brainstorming session with my peers to further breakdown the elements of the execution (i.e. follow-through) of a task. The following were elements were discovered:

  • Shame
  • Accountability
  • Feeling of Accomplishment
  • Amount of Time

With these elements in mind, I began the ideation process of how my app could take the above elements into account to ensure the successful completion of a task.

Break down of the ‘follow-through’ of a task.

Ideation of the Product

From the discovery & research process, I theorized that the likelihood of completing a task was increased by use of external suggestion. I imagined this as a module within the app that would provide recommendations to complete the task, per the task entered. For example, if the user entered “Find a Babysitter” as a task, the module would present profiles closest to the user to help facilitate the process of finding a babysitter. This module would help solve the following issues related to the execution of a task:

  1. Reduce shame as it would provide knowledge on how to complete the task.
  2. Reduce time to complete the task, as it helps provide ‘shortcuts’ to completing the task .

I illustrated a storyboard to ensure the logic of the app made sense. I also created several user flows to understand the choices the user would have to make in using the app.

Storyboard including use of theorized module
Basic wireflow initial concept

Testing the Iteration

With the above solutions, I interviewed my peers to see if these solutions were indeed sensible and viable. I am very glad I tested, because my theory of the use of an external suggestion module was flawed. The users I interviewed believed the module produced too much choice, thereby countering the purpose of the app. Further, it was discovered that the use of a reward was ideal for completing tasks. It gave users something to look forward to. If the external suggestion module could be simplified, then it could become useful.

It was time to start sketching.

User Interview Notes

Sketching Out Ideas

With the information I collected in mind, I began sketching out how the app may look like, including the ideas of simplicity, reward, and a revised suggestion model. Based on the user interviews, it had to have an incredibly simple interface and very easy to follow. It could not overwhelm the user, as the app’s goal was to execute the necessary tasks. I began with several iterations.

Main Task Screen
Reward and Task Entry Screens
Reward and Task Entry Alternatives

After getting an idea of how the app would visually appear, I refined the sketches to produce a viable wireframe.

And refined some more.

Refined Wireframe
Refined Wireframe (Continued)

Testing the New Iteration

After developing a presentable wireframe (see ‘Refined Wireframe’ images above), I tested the model with users. Users would be prompted with screens to enter the three most important tasks for the day . They would then be prompted to enter a reward for completing their tasks. If the users needed help, they could click for the dots next to the task for more information. The module could then present solutions to complete the task. After completing their tasks, the app would present them their reward.

The simplicity resonated well, as did the use of the reward. Users said the app was easy to follow and they liked they had to limit the number of tasks they entered to only three tasks. However, the module was still incredibly confusing. They didn’t know where to click to get more information on the task. Once the module was open, they didn’t know how it presented the information.

With this information I tried to redesign the suggestion module. However, I found that this was becoming too complex.

Button design for suggestion module.
Layout of suggestion module.

The module was finally cut out of the app.

Further Usability Testing of Wireframes

Alumni from previous General Assembly UX Design Intensive cohorts came to test our app designs. Through their feedback, they stated the app felt like too much of a form. They also stated that the number of tasks the user can input should not be forced to three; there should be more flexibility in the app.

As a result of this testing, the user could now input up to three tasks maximium and this could be achieved on one screen.

Updated Task Screen

Final Prototyping

With the modifications made based on the suggestions of the GA UXDI alumni, I did a final user test. The user was receptive to the new task entry design, and did not find it as confusing as the previous 3 screen task entry process. They understood the design and the goal of the app.

I proceeded to develop even more detailed wireframe models to mockup the app in Marvel.

The below is a screenshot of the final prototype. The link to the prototype can be found here:

Main List Screen