Why am I publicly critiquing my dirty laundry

I recently had lunch with Chris Hanrath at Strava. As we talked, a few things became apparent.

  • Making an app as successful, beautiful, and usable as Strava is a MASSIVE undertaking.
  • I may have missed a few edge cases. (oversights > 0)

All joking aside, it brought up a very real challenge to building a portfolio. Successful design not only incorporates the user’s experience, but also considers the limitations of the business. Tradecraft does an incredible job of providing real client work for us while we learn- but inevitably we also make projects without a live client. It’s easy to design in a vacuum (see: dribbble.com) but much harder to design with real life people involved.

In an effort to show due diligence, and in order to create a better project, I tested/validated/broke/started-over multiple times based on user testing. I point this out not only to grant my portfolio more legitimacy, but also to provide a project with context.

My "completed" work (usability testing, personas, etc.) can be see on my portfolio site here: Strava Project

Below is a graveyard of my project. Edison is famously quoted as saying “I have not failed 700 times. I have not failed once. I have succeeded in proving that those 700 ways will not work. When I have eliminated the ways that will not work, I will find the way that will work.” Below is my 700 ways to not add a feature to Strava’s mobile app; a personal critique if you will.

FIRST ITERATION: THE "RUSHING TO UI" PHASE

THE STORY

Effectively this is what happens with you move directly from wireframes to a UI. Blocks become text and text becomes jibberish. This was thinking very much inside the current interface of Strava's activity feed. The users I tested with were familiar with the interface, but struggled to really comprehend what information they could see and how/why they would want to see it.

WHAT WENT WRONG

Adding stuff to an already functional interface is rarely idea, and that is exactly what this attempt was. Utilizing an existing paradigm is great as long as that structure supports the new intended function. In this case I underestimated the number of new assets that would have to be added to an existing interface.

WHAT I LEARNED

Designing within brand guidelines is a very real situation. Attempting to keep everything exactly the same while adding in a ton of functionality is not. I learned to have a reason for every asset of my design and include aspects of the design "just because".

SECOND ITERATION: I AM GOING TO GIVE THEM ALL THE THINGS!!!

THE STORY

"I had done my usability testing. I spent hours sketching wireframes by hand. I made a boxey wireframe prototype. The UI basically just makes itself after that, right? I can definitely dive fully into pixel perfect mockups."

This is effectively where UX and UI intersect (they are very different and separate roles no matter how many people post jobs for UX/UI). I had done my testing to determine the pain points and worked through the task flows that I thought would solve them. This does not mean all that is going to fit onto a 750 x 1334 pixel screen on the first shot.

WHAT WENT WRONG

I got ‘how much data can you provide’ mixed up with ‘how much data should you provide’.

The first user I interview gave me all I needed within the first 30 seconds. Generally the phrase “whoa there is a lot going on here! Give me a second to figure it all out” is an indication that your design didn’t come across exactly as you had planned.

WHAT DID I LEARN

The most well-intentioned and well-thought out wireframe boxes can still be filled up with shit. I really had to take a step back and examine what exactly my potential users wanted, but more importantly what did they need.

THIRD ITERATION: WHAT DO YOU MEAN YOU DON'T WANT A HEAT MAP?

THE STORY

I took some steps forward from the initial design, but some steps backwards as well. Visually, I took user interview feedback and added some visual distinction and contrast to help people track different sections of the design. I also got feedback about a obvious starting point- people wanted to always land the same place and always know how to get home. Strava Labs has done some incredible work developing heat maps of rider data. (and using it for great purposes http://blogs.wsj.com/digits/2014/05/07/strava-popular-with-cyclists-and-runners-wants-to-sell-its-data-to-urban-planners/) Apparently I figured that anything cool deserves to be cramped into a mobile screen and rendered useless.

WHAT WENT WRONG

User tests certainly went better... Users were able to identify individual blocks but still unable to comprehend quickly what information was in front of them. 

Although the visual contrast does break up individual cards, all the cards effectively have the same amount of information. On top of that I added in a vanity feature. Strava's heat maps have really powerful uses, but a mobile dashboard is not a viable use case- no matter how cool it might seem. Now users can chunk the areas they are supposed to be looking at, but can't focus in on what is inside that.

WHAT I LEARNED

I need to have a reason to do include something on a UI. Ideally I should have multiple reasons, but absolutely no less than one! Relying on a simple visual cue (like color contrast) is a start, but cannot make up for a cluttered interface. It was crucial that I remove my bias from the design. I knew where everything was and why I put it there- but unless users can interpret the interface is remains useless.

FOURTH ITERATION: "NO. LOOK, I WILL EXPLAIN IT TO YOU WITH AFTEREFFECTS."

THE STORY

Like any designer who is stuck on a designer, I began to think that I just wasn't communicating it well. "People will totally get this once they see the interactions". So I made some additional revisions based on the previous phase's interviews and took off into After Effects. 

WHAT WENT WRONG

There probably should be a proverb that states- "any flow that needs high fidelity interaction to prove its worth is certainly not worth much." I was short-sighted on the really valuable feedback I was getting. Instead I fixed the problem users were directly complaining about without taking the time to understand the root cause of why. 

WHAT I LEARNED

While interaction animation is extremely valuable, it should not be required for a user to understand the basic structure of a feature. I learned that instead of forcing the user to understand my vision I needed to understand theirs better. I found that taking a step back and thinking about the user's expectations and needs rather than focusing in on.

FIFTH ITERATION: TAKE AWAY EVERYTHING

THE STORY

One of my favorite design quotes comes from Antione de Saint-Exupery and translates roughly to "...perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away...". By no means am I implying that I am close to perfection here, but I was striving to remove everything I could and still have the concept function the way I thought it should.

WHAT WENT WRONG

This is a case of what the right idea is the wrong thing. I purposely took away the explicit ability to move between cards in the interface, instead only allowing users to swipe left and right. I this to explore their mental model- what did they expect to see? By taking away too much, it became more obvious what the minimum interface to add back in.

WHAT I LEARNED

This was a very simple lesson that was very powerful: "sometimes the best design decision is to do the wrong thing.

CONCLUSION

I absolutely, 110%, learned more in my failures than in my successes.  The biggest thing I learned overall is that I have to test feature designs over and over again until I can no longer break them down. I found that if I attempted to prove my hypothesis wrong, rather than correct, I was able to think more objectively. Utilizing the framework of Lean Startup, failing early and fast allowed me to arrive a viable solution rather than a visually pleasing, but useless, example of UI. It was very important for me to develop a useful and working feature, the only effective way to do this is put in front of real people.

I hope by publishing this I can constantly be reminded to be mindful that no design is ever over. I also hope that others can learn from my process. There is no shortage of UX literature preaching 'fast & iterative' design, but rarely does the reader think about what that really looks like. This is what that iterative process looks like.