Want a killer UX? Wireframe and iterate

This post is about how to iterate on UI and deliver a stunning user experience to end users on a shoestring budget. The secret is to do it the old fashioned way: wireframe it first, then make compositions, then test the storyboards with users, then code it up.

I’ve been part of several development projects where my project team was forced to cut corners on up front design.  Sometimes the product management and design teams were busy doing other stuff.  Other times (GASP!) the company didn’t actually have product managers or designers.

Typically the feature would be communicated in the oral tradition.  If we are lucky we sometimes get napkin sketches.  Engineering is then requested to code it up so we can “see what it looks like”.  The requirements are generally very sparse, marginally communicated, and the user workflows are not thought through.

This of course results in something with a UX that is at best rough around the corners and at worse inexplicable.  Changes are requested, new code is written, and this cycle repeats itself until the project overrun is intolerable and the feature is released to the wild with multiple compromises.   The project ends up taking 2 or 3 times as long as it should.  We get lots of 1 star reviews.  Everybody is cross with everybody else with how things turned out.

Instead of rushing to code stuff up, if the PM and designer take the time to start with user storyboards, flow charts and wireframes, iterate until mainstream use cases are solved, then move to the compositions depicting the graphical layout of every screen in the feature, and then validate with end users, the exact same project would take half as long in elapsed time and will work 10 times better for the end user.

This is because the PM and interactive designer have the best access to actual end users, and are the most qualified people in the company to dictate how the feature works.  Also, tools like Microsoft Visio makes it possible to do 20 iterations on a wireframe in a day, whereas it is simply not possible to iterate that fast in code.

In a startup environment, we sometimes measure success by the wrong metrics: we equate speed to market to success.  A better metric would be speed to market with a great user experience and satisfied customers.    It’s much better to invest up front in a good design – you will save money and time in the final analysis.

A year in review

As the year draws to a close, it’s time to reflect upon the good, the bad and the ugly in this year.

• We did a really cool segmentation and ethnography project that helped define buyer and user personas. That was great fun.
• We did a bunch of pricing research on the cheap, but the results were inconclusive.  Probably should have hired professionals to do this (a casualty of working for cash-strapped startups).
• We built a strong, diversified, talented and productive software team.  This makes me feel like a million bucks.
• Said team figured out how to develop and self-host a scalable web based application. That felt great.
• We launched a new iPhone App.  That felt great.
• We had several intense “Oh Crap” moments. That felt crappy but all’s well that ended well after we fixed what’s broken.
• We launched a massive new project with a ridiculously aggressive timeline. That felt scary.
• We are miraculously on schedule 1.5 months into said aggressive timeline. That felt great (even though I still come close to passing out each time I visualize my 390 line Gantt chart in my head.)

At the end of the day, everything that was achieved at work was achieved because we put together a fantastic team of trained assasins who are super good at their jobs, yet flexible enough to adapt themselves to the rapidly changing needs in a startup environment.  I’m very proud of my team and all their achievements.  They rock!