Build it, learn it, tear it down & start again
Lessons learned in product development
What makes a good product? Is it something you use instinctively without thinking about it? Is it a sexy design with loads of the latest web animations? I don't think so, I think it boils down to the simple task at hand: does the product meet the function, and does it function well? Anything else you add is superfluous, it's the classic Bauhaus movement... function over fashion.
If you look at current websites for example, the trend of animation with '3D flat design' (or whatever's hot this month) focuses more on animations than user experience, especially when you look at time spent in each area during a project. The same could be said in most other fields, take pop music as another example, and ITV’s X Factor; so much emphasis is put on style, looks, stage presence and theatrics, yet there's never any nurturing for songwriting. In fact the opposite happens, young hopefuls with bags of talent have to leave their own creations at the door and sing chart toppers. And we wonder why only a handful of finalists have seen success…
So what do we know about Product development?
I've been building, managing and maintaining digital products in some form or another in my 5-year career at 20/20.
Started by my predecessor, we built our first product, DelegateManager to satisfy our own event management requirements. And, since I joined the team, we've redesigned, reconfigured, enhanced experiences and built new features. Also, we're currently working on a complete rebuild to improve security, support and enhance our product features. And that's just one of our three products.
There many tried and tested methods for development out there, the most used being the wireframe->prototype->develop method. As much as I subscribe to this and fully understand the reasoning, I think 37Signals (the Chicago based company responsible for Basecamp) got it right with their 'Getting Real' method;
"Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing."
Jason Fried, 37Signals
I'm not saying that the standard method is wrong, or that 37Signals don't employ this method to a degree. I'm saying sometimes you have to jump in at the deep end, strike while the iron’s hot, use that momentum to build something beautiful and address the issues when they arise. Most developers would call this stupid, and probably irresponsible, but I think the best work, and the best features, come out when you start tinkering, and before you know it, it's 2am and your worried the kettle's going to make too much noise and wake the kids up! I personally adopted the ‘Get Real’ method (read it online here) a number of years ago after we started using Basecamp in the office (back when its was still Basecamp Classic), and have incorporated it into out way of working, where applicable, ever since.
No process is flawless, and no project is without its obstacles. When we originally built our Smoke Signal product, we used Flash with ActionScript2 (which was old when we created it). I built the original system because, at the time, it felt like the right tool for our requirements and I knew AS2 reasonably well. This, in hindsight, was a mistake, but it allowed us to evaluate what we had done, rebuild and reevaluate. This evaluation process, I feel, is the only true way to tackle product development, simply because it's impossible to get it right the first time – especially when you’re not sure what the full scope of the product will be, and what the capabilities are. We never anticipated our product working in the retail sector, but it's surpassed our expectations. This is purely because we didn’t pretend to know all the answers from the outset. Since its creation, Smoke Signal has gone through two complete rebuilds, and numerous iterations. It's more stable, more customisable and more reliable than it has ever been.
Similarly, when we created our first app, an Android app to capture audience feedback for a specific roadshow event (here’s a link to that project), we had several obstacles to overcome. The largest being the time constraint – I think we had three weeks in total to pull together an app as well as a syncing system to capture all the data. There was no time here to prototype a concept and create a development spec document; we just had to understand the requirements, come up with the simplest method to achieve our goal, and get it done. Sometimes you have to work to crazy deadlines, it's part and parcel of our industry, but you'll probably do your best work under that kind of pressure. This particular project won awards, earned me my first professional commendation, and is one of the things I am most proud of in my career.
"Where do we go from here?"
That’s the question that, I feel, plagues a product designer more than anything. Do you admit when the concept’s been fully realised and no longer requires input? Do you jot down ideas for the next project?
Thankfully, I'm at a point where I know what's required; DelegateManager's in its second development phase, with future features already "gestating", Smoke Signal is only at the beginning of its capacity and Control Tower (our 'added value' custom built CMS) still has a few features left to implement.
Plus, our clients always have new ways of challenging us, which really encapsulates the purpose of product development – problem solving.