Getting it Shipped: a lesson from my makeover

by Tim M on March 31, 2010

Website makeovers can become horribly corrupted, go way off course from the original intent, and sometimes end up hopelessly compromised, and even go undelivered.

I’ve been doing a lot of reading lately, particularly of Seth and 37Signals, and their lessons as they pertain to my goals in overhauling were highly instructive (seriously, if you want to learn what works, and get way more intelligent about business, read these guys, specifically: Rework and Linchpin).

The key insights I gained from these guys (Linchpin, Getting Real and Rework) is that winners get things shipped. There are a whole lot of points around good (defensive) web design, which you can read here – a must read!

I thought I share some of the insights and key points so that if you are overhauling your site, you can learn from my mistakes and victories.

Please note my redesign is here: it’s far from perfect, and there’s loads to do, but it’s a good start. If you’re a UI/UX ninja and think I have some stuff that is completely wack (“OMG, Tim, WTF?”) drop a comment or email me on what I need to do (it might lead to work for you!).

The Story. was a good idea, but poorly executed, at least from a UI and UX point of view. My key goal in getting a cheap and “nasty” version up quickly after I conceived the idea, was to provide people a platform to share their best coffee experiences with others to ultimately lift the standard of coffee everywhere (a noble goal, although very large).

I always planned to fix the UI and UX up, whilst maintaining a simple, focused site that brought people together and created a network.

So once I had the platform up, I knew I had to make it ultra easy for people to use and share, and best way to do that was to give them something beautiful to look at and beautiful to use (and of course, being highly useful).

The best way to achieve this I thought, was to split the work into 2 main areas: look and feel, and back end functionality.

The smartest way to do this was to knock off low hanging fruit – look and feel, and things that made submitting a review as easy for people as possible. Actually not “easy” but beautiful.

Look and feel could be accomplished by applying a skin to the site, with no other changes considered.

So, I came up with a list of things needing rectification (complex and simple), which I got from usability testing with Chris L (thanks man, you were invaluable) and from what I could see, and away we went.

Back End makeover.
The goals
I wanted to submission form really, really easy to use. A joy to use.

I wanted errors gracefully handled. When people were at their most confused point, I wanted the site to help them resolve the issue. I never wanted people to be left angry or confused about what was happening.

What happened

I thrashed early, and hard. I got people involved, chose a handful of friends, and thrashed through features and functions deemed absolutely necessary, and those nice to have. One of the strong lessons I got from Linchpin is that successful linchpins (shippers) ship as a matter of habit. Simplicity, and constantly shipping requirements was key to meeting this maxim.

Once I had a great list of things, I went to Elance.

I engaged a guy from China who seemed to know what I wanted, and things proceeded nicely. He answered my emails, was getting stuff delivered, and all looked peachy.

However, things then went badly. It’s a story for another time, but to cut a long story short, I had to cancel the job. You need to know when to quit.

I then re-listed on elance and awarded the job to someone in Mongolia at a hefty premium to other quotes based on his excellent English and other projects I could find on the web.

This was a disaster. We got off to a good start, but things quickly went sour with him not answering emails, trying to change the terms of the engagement, and simply not delivering. In the end I had to cancel the agreement.

Out of sheer desperation, I posted a “Help Needed” on this site, and immediately got a response from Daniel at Doomstick (Daniel, what on earth is a doomstick?!), confirming he had the chops and could start asap.

I deliberately broke the work into an initial portion to allow me to assess his capability. I was not let down.

Daniel delivered the goods, so much so, that we ended up doing all the work, plus subsequent scope creep, in 4 phases (and we have plans for a lot more). I plan on working with Daniel into the future. He’s got excellent communication and coding skills, and I always sought to get his input into my implementation ideas, as my ideas are one thing, but the practical implementation of them is another. Rather than epic code bloat due to my insane ideas, I’d rather underdo the site and make something kick #rse, instead of half-#rsed.

My budget was shot to pieces, but in this case, it was worth it and I think my budget was way too low to begin with.

How we Collaborated
Daniel and I worked based on trust. We collaborated using a set of requirements in Google Docs where we could park scope creep into subsequent phases and riff with each other with one column each for comments, with new entries being bolded. This was better than email. Way simpler.

I had an in-development section, a bug section, a completed section and a to-do list. Maximum transparency.

Once something was marked done, I tested the functionality on the test server, which had a copy of data from the live site. Once it met the requirements, that’s it, done. Next! (Remember, you MUST ship, even if it’s a simple requirement).

We kept repeating this process, killing bugs, until I wrote SHIPPED! in Phase 2B (which followed Phase 1 and Phase 2A).

Front end makeover.
To be honest, after seeing Lauren’s site, chatting to her about what I wanted to achieve, and then getting a quote from her, there was never really any doubt about who to use. Lauren is an artist. She’s clear, forthright and can-do. I cannot remember how I happened upon her (perhaps it was Smashing Magazine), but I am glad I did.

With Lauren, there is no scope creep, which is critical to getting stuff shipped. For some people, hearing “no” or “not in scope” can be galling, but for me, it’s perfect.

Nothing is too big a deal for her, and she is unfailingly polite, and chirpy (which is a good balance to my direct, almost blunt, manner) human being.

We agreed on a scope, a cost (no timeframe), and away we went.

Lauren and Daniel communicated where needed, which made things way easier for me (I hope you guys didn’t mind).

She’s my go to person for design now.

The delivery time frame
I started this around August 2009, and delivered something that met most of wherespresso’s user’s requirements in March 2010; 7 months. I had originally intended to have this delivered before Christmas, so as that deadline passed, and then another, I began to feel agitated.

The delays impacted on the delivery of my iPhone app, allowing one of my competitors to get to market first. I had to remind myself being first to market never matters. Being *best* to market does (Google, anyone?).

At least on the shipping on time metric, I failed, or at least felt I had.

On reflection, I had nothing to ship, so delay was needed (a nice postscript to that is that the delay allowed me to read Defensive Web Design, which completely changed the design and function of the site for the better).

The lessons
Here is what I learnt from this. In no order of importance.

  • Get someone who speaks your language natively, or near natively. I believe this is critical in understanding context, especially if one of the party is Australian – we have a very strange vernacular.
  • Break your work down into portions that reflect their benefit to the user. There is absolutely nothing wrong with picking low hanging fruit that removes several points of pain for the user quickly and cheaply. If they can prove themselves with small tasks that can be executed quickly, you both win; you get pain points removed to the benefit of the user, and you can move on to tackle the big stuff.
  • Go with someone who has a transparent history of delivery. Daniel and Lauren both have that. If the person has a site, with links to projects they’ve completed, that’s an excellent start. Forget the resume and spin, Google has everything you need.
  • Always wireframe your screens and functionality. I gave Daniel wireframes for UI screens, and use cases for UX/workflow. Functional specs are not functional.
  • Find an artist with a history of shipping (yes, it’s that important).
  • Don’t write a functional spec, they are not functional!
  • Read these books! Getting Real, Defensive Design for the Web – at a minimum

Anyway, this would not have been possible without the following people:

  • Kate: never complained when I was on my laptop, even when we were in Hawaii. You’re a gem!
  • Lauren and Daniel: you guys are incredible.
  • Everyone who helped push this along (Chris L, this means you!)

We should all be so lucky to have such amazing support.