Think it. Code it. Ship it. Test it.
The start of a project is rife with excitement and energy. You're feeling good, the team is feeling good, the boss is feeling good. Good? Good.
You map out a rough plan, you start working through initial concepts, mockups start coming together. It's all coalescing quite nicely. And then you start meeting and presenting. First round bleeds into second bleeds into third. Lots of talking online in a big room. Lots of talking offline in a hushed IM. Email abounds. IM intercepts. The clarity that rang so true in the beginning of the project becomes muddled. You curse the client. You question your teammates' judgment. And you take a long, hard look at yourself and know you're not helping things much either. The train's gone off the tracks. "I don't care what decision we make, just get that fucking thing out the door."
And you know what? That's a good thing. That is exactly the sentiment that's going to get us back on track. Here's why.
Think it. Code it. Ship it. Test it. Keep it simple. Keep it clean. Don't overtire the team. Don't inflate the process. You'll get a better product out the door, and have some real usage to analyze and build on in the next round. No weak knees, no endless droning about in usability testing. That's how great things die a terrible death. More on that in next month's post.
1. Think it.
But don't overthink it. Got smart people with good heart? Put them together in a room, let them hash it out, trust the group's business savvy and UX experience. The key is making sure you have the right skill set and panache assembled. And don't forget the visionary. A pragmatic visionary (one on each side of the fence) is a very good thing.
2. Code it.
With ace developers on the team (and a few crackerjacks thrown in for good measure), get a good foundation in place, vett the architecture, and follow modern-day best practices for back-end dev and front-end dev. Your code is only as good as the experience and perseverance of your dev team.
3. Ship it.
Wait, ship it before testing it!? You're kidding right? Here's the thing, you do need to make sure shit's working as it should be (i.e., from a functional perspective), but don't get bogged down in a bunch of arcane, traditional notions of usability testing (traditionally conducted in an artificial environment) and user acceptance testing (traditionally conducted with stuffy internal folks who are out of touch). You'll end up spinning your wheels and losing out on valuable real-market, real-user learnings. Make sure stuff works well and looks good, but don't start second guessing at this point in the game.
4. Test it.
After it's shipped, get some real insight based on real usage. And yes, I've over-used "real" here, and will continue beating everyone over the head with it. Any user testing you do before you release it into the wild will just result in a bunch of artificial results from people who are being forced to form an opinion in a simulated environment. Not good, not useful, and a complete waste of time and money. Test in the wild if you want real feedback.