Designing our mobile experience

Application development is no small task. To do it well, companies typically start with a long and meticulous planning process for its development. Even using an “agile & lean” approach, a successful launch often follows a trajectory of build, test, have a beta release so you can conduct usability reviews, correct bug fixes and then wrap-up features.

 

Not TripLingo.

 

From our first days we had ambitious plans. In just two days Jesse (our CEO) had us convinced that we could not only take on any and all current language learning companies, but do so with a fresh approach and a better product. During this hurried introduction, he presented to us his initial design concepts that he created while in India.

 

 

My goal here isn’t to pick apart any of our design progress, but instead to give you a behind the scenes look at the evolution of the early development of our v1 mobile app.
I’ve created website designs and applications for years, and I have always labored over each screen conscientiously to ensure the best possible experience from start to finish. After launch I would gather and analyze feedback to fine tune the original design. With over a decade of UX experience and being a proud proponent of data-driven design, I understood that for our first release we needed to focus on context, ease of use, and simplicity. Jesse did a great job of providing us with a solid concept and tons, tons, seriously way too much data for a 2-day event. But keeping things simple proved more difficult than initially thought.

 

From scratch

During the initial day, after introducing ourselves we quickly divided into separate working groups. I took lead on creating the GUI & began working with Jesse and Matt to conceptualize the user experience. Looking back, we spent WAY too much time creating wireframes for what was supposed to be a v0.1beta, mocking up more than a dozen different screens, many with features we have still yet to implement. Granted, since we did win the event and another, and kept steam rolling on as a company, the time spent was not in vain; nonetheless, for our goals of launching a v.1 in a weekend, we should have focused much more on the actual implementation.

 

 

All the pretty colors!

While the last few months have seen numerous changes and modifications to many of our initial decisions, the foundation for what the app is today was created during StartAtlanta in a matter of seconds simply because we just needed to get something done — and a plentiful amount stuck.

 

Our lovely blue & orange color palette was initially selected by myself unpretentiously. They are my two favorite colors. The blue has no back story. I just like blue. Pick almost any variant form of its shade and I am a fan. Our ‘Egyptian Cotton Orange’, as I like to call it does have something of a back-story: I have forever referred to this color as a result of my ignorance with bedding thread-count and their naming conventions while shopping with my wife. Long story short, my first encounter was with orange sheets (that is, “Egyptian Cotton Orange”) and the name stuck. Apparently Egyptian cotton is revered as a primo type of bedsheets. I just liked the color. Whatever.

 

The color selection was welcomed by everyone (even Jesse who later told me how much he hates orange- I think he’s come around though). James (our Creative Director) helped refine our blue and orange to what they are today, including a specific web-compatible hex value. He also labored over our logo, I’ll make sure he writes a post about that process soon.

 

We like blue & orange not just because they’re my favorite colors, but also because they convey things to our users subconsciously. The blue represents loyalty and a passive tone of relaxation. It eases your mind. The orange represents the energy of travelers on their excursions. The blue and orange complement each other and their combination of colors represent our goal for TripLingo’s brand– trustworthy & enthusiastic.

 

The secondary colors found throughout the app also complement our brand. The yellow reinforces the vibrant nature of which you will use the app, but also evokes a cheerfulness. The light blue acts as support for the more vivid colors by allowing them to easily contrast in the UI. That’s essentially how our colors were selected & perfected.

 

Version 50 in 2 weeks

Because I genuinely believed in the idea right away, and because I’m a bit of a perfectionist, I wanted to make sure we accepted nothing less than perfection. This conviction was shared by all, and was a key aspect of our culture from early on (which also gave us permission to vociferously debate any aspect of our product, no matter how small).

 

Make no mistake, we all still believed in shipping a lean Minimal Viable Product (MVP) , but our desire to get it right meant that we created an insane iteration process on the v1 features we decided on.

 

Design, discuss, tweak, re-design, discuss, tweak, more re-designing, discussing, show people, tweak some more — all in a matter of hours. This process went on constantly through the 12 weeks leading up to launch, and by the time we got there we actually ended up looking at almost 50 different versions of the dashboard, flashcards, learning mode and all the other screens.

 

 

For each iteration the goal was always the same: to make it better for the user. Of course there is nothing like getting actual data back from users about your product; yet because of our time constraints many of the decisions were done on instinct and experience. Plus there were 7 of us, so we had at least 7 users to test on at any given point. And yet after all of those iterations, there is still so much to be done. However, it’s imperative to launch at some point. You’ll often here us quip “Ship It!”, as we all share a strong fundamental understanding that we’re not at war for features, but instead a battle of emotions.

 

A great product is never truly finished; but eventually you have to hit the launch button.

 

99.9% custom & proud

When we began our initial discussions and breakdown regarding concepts and GUI (graphical user interface) designs, our united and immediate thought was to make sure this was something different. The flow and design had to measure up to the innovation of the idea itself- it wasn’t “innovation for the sake of innovation”, but part of the problem we saw with other solutions was the UI, and we knew something better could be achieved. And even the best ideas can be squandered with a horrible interface and flawed user experience design (and vice versa). So, although we quickly agreed to use the awesome Appcellerator Titanium framework which would have allowed us to rapidly create a UI that uses native components — we opted out.

 

We ended up using only three native GUI element in the entire app- two text input fields and a “cancel” button in the dictionary were it. For the rest, we experimented with a variety of different animations and button layouts. We used our speech bubble motif throughout the app. Instead of loading separate views, or even default modals, we animated little bubbles. Even the ‘open in safari’ button and popup is custom. Progress bars, switches, modal windows, practically everything. I felt very passionately that this would make us stand out aesthetically, though more importantly these changes were instrumental in making many of our features functional, useful, and intuitive.

 

 

Without question, I’m very satisfied with our v1, but maybe I’m biased ;) With that, customers are also constantly validating our choices. With that said, I have to reiterate that this is our v1. We are just getting started with our iPhone app, not to mention all of the other devices we’re working on. There simply just isn’t enough time in the day to actually do everything that needs to get done. But its not for lack of trying, we can only move 2x the speed of light — we’ll get there soon.

 

So, I’ve tried to give you a picture of some of the thinking and process that’s gone into our UI. We thrive on feedback, good and bad, so bring your expertise to the table and let us know how you’d do it better (or what you’d leave the same!).

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>