Protoype 1 - 11 never made it to the final version but were important for understanding the UX bottlenecks

Before jumping into the details let me express how - as a designer - brainstorming and ideating about the UX of a project is the easier part, the difficult part is understanding who your endusers are and what they want to see in the application you're going to create.

Sometimes

When you design a project and put it in the hands of your audience to use, you find flaws and bottlenecks in your design that you create. Turns out this is as normal in designing complex user expeirences as anything because design is an iterative process.

However, in the case you do find bottlenecks in your design and realize that what you have worked on doesn't work as expected, what is the next best step to take and how to approach the feedback?

For past few months of writing this blog post, I was involed in designing a productivity application. This application is suppose to help its users improve focus and maintain consistency in doing work.

Initially

To design such an application and to find how other people might want to use it the design thinking process was applied to the problem and starting from interviewing potential customers to diary keeping and ideating.

Alot of cool stuff regarding the problem set was found, and people were interesting in using such a tool because of the growing workload in the digital age is a real issue and people like digital tools that can help them do more.

If you’re interested in the process read the full case-study here

Two Hours (Case Study)
User Experience Design project Introduction A lot of people I know, including myself, struggle with time management not because of laziness or unwillingness to be good at it, rather, these days it is very easy to get distracted because of the amount of information that is available at our fingertip…

Here are the findings from the above case study in a gist

1. People like to work in sprints

I found people who are good at time management like to divide their day into modules. They allocate time for a specific task and focus on it completely rather than switching back and forth.

2. Two hours is the limit of productive focus

I found 2 hours is how long it takes to get something done while maintaining maximum focus and productivity. I found techniques like Pomodoro which promotes 2hour focus and people like Einstein who spend two hours on important things.

3. Consistency over intensity is the key to success

Consistency is important because it builds momentum. When you do something consistently you develop a routine and form habits. If you’re consistent you perform at a higher level. It builds credibility and accountability.


"How can a tool help someone increase productivity and maintain focus and improve consistency at the same time?"

This question became the goal of the UX design and it all boiled down this statement

“If you spent two hours doing something and you do it every day you will see good results!”

It made sense on paper, and the idea was well received while testing low and high fidelity prototypes but it got tricky when it was made into a working app.

Where it went wrong?

While usability testing the users requested extra features and I decided to add those features in the design because I thought more features mean more fun.

I expanded the scope without thoroughly evaluating and optimizing the UX for the core features.

An argument can be made here; A working application on user devices can represent the user experience more accurately than testing on makeshift prototypes.

Testing on a user device is more feasible now thanks to developer tools like SwiftUI! Which lets you code real apps quick and early in the development cycle.

Having said that, adding more features was proven to be a big mistake when an MVP was distributed via test-flight. I found the core of the UX has flaws which needs addressing. All the extra features were confusing the user.

Feeling miserable is a part of the process!

Looking back at your mistakes is the worst and the best part about being a user experience designer / developer. This is when I found Danial Gauthier’s blog.

Going indie, step 1: Come up with an idea
Back in the early days of the App Store, a prevailing sense quickly grew that all you needed to become an overnight success was a great new idea for an app. ...

Dan said what I needed to hear

  1. Cut the scope ruthlessly and focus on the minimum.
  2. Build your core interaction loop and tune it before anything else.

I wish I stumbled on this advice a few months earlier which would have saved time.

The principle of retrospect

The silver lining here is that design is an iterative process. I remember reading one of Tuhin Kumar's blog on great designs in which I read

“Great designs are usually the result of a lot of trial and error, missteps and blind alleys, and hard work and deep thinking… No one gets it right the first time.”

http://tuhin.co/great-designers.html

So whats next?

Now that I made something which doesn’t work, Tuhin's blog is starting to make more sense. Now is the time to look back and understand the user feedback to identify and fix mistakes.

To be honest, I have no idea if I am going will be successful in finishing the project in time or at all, but I know where I made the mistakes and where the design needs to improve.

For example, here is the feedback collected from the users which I am going to work with next

Feedback from usability tests

  1. What happens if I spend more than 2hours on an activity?
  2. What if I want to work on something for 1 hour or maybe less?
  3. What if I want to take a break and pause the activity for a bit?
  4. What if I am not working on an activity that I planned and would like to reschedule?
  5. What if I want to customize the time and work on something between let's say 11 and 1?
  6. What if I go to sleep later than the app thinks I will and have 6 hours of sleep?
  7. I didn’t know if I was supposed to swipe the cards at first glance.
  8. There weren’t enough reports about consistency or positive feedback loop.
  9. I don’t understand the 2hour sprints… why two hours?

Here are the major points I will consider in the next iteration

Points to consider in the next iteration

  1. Rescheduling/deleting an upcoming task.
  2. Allow breaks and no activities.
  3. Consistency reports and recommendations.
  4. Adding another sprint after the last sprint.
  5. Scheduling something between odd timings.
  6. Taking pauses in the sprint.
  7. Removing the countdown timer.
  8. Create a sprint as you’re working on it.
  9. Create a sprint while taking a break.
  10. Explain the two-hour rule.

Conclusions

The fact that I didn't go as far in the initial discovery phase as I shoud have has merits. After the interviews and initial ideation a prolonged diary study with different type of potential users would have helped in answering most of the questions I got from users who tested the on device prototypes.

However, since creating on device prototypes is an interesting frontier because of new tools like Figma and SwiftUI the end results and the concluding remarks on the design were the same. Which made it a fun, leaning journey in the end.

The final take away is the end goal of the product is much clear now which is about "finding a way to track and manage the demands of all the parallel threads of their life, particularly aspirational goals like learning a new language". I am looking forward to the final product when it launches end of August 2020. If you want to test a beta send me a DM on Twitter and I will invite you on Apple's test flight program.

Thanks to poodleface and many others for their interesting insights on the topic.