Haste makes waste

I watched “The Killer in Me” a couple of nights ago and I’ll save you time that you’ll never recover by saying don’t bother. IMHO it was pretty awful. However I will give it credit for the title of this blog, "Haste makes waste," as it summarises perfectly what I want to say here.

I was privy to a large debate about new features and enhancements for a critical internal application. One user-friendly person offered up the suggestion that instead of just collecting a bunch of features and requirements that someone should take the time to do some quick wireframes and then do some guerrilla-style testing with a handful of users. Seemed like a sensible idea to me. However it was met with the following (paraphrased) response:

‘I beg you not to design and test before coding – get coding as quickly as you can and if it doesn’t work change it. The idea of UX before code is outmoded and needs to change…’

Actually what is outmoded is building software that is bloated with features that are either not used, not wanted or are so unusable that they are not used. Coding from a bunch of business requirements without considering the overall experience produces exactly this kind of ‘bloatware’. I do subscribe to the notion of getting to code as quickly as possible and that big-up-front design is wasteful but answer me these two questions?

Question 1: How much time would it take to build a working application (even in Ruby-on-Rails or the like) with fifty or so fairly critical features?

Answer 1: from a random poll of devs, the finger in the air answer was 2 x 2 pairs of dev (4 people) 6 weeks for the minimum critical features.

Question 2: How much time would it take to rapidly, or even better, collaboratively, sketch the application and get some quick feedback on what’s working and what’s not?

Answer 2: from a random poll of nearby UXers the finger in the air answer was 2 days to collaboratively sketch out the UI/user experience with users.

So If I follow the first path 1 I will have working software within six weeks (which IS cool, no doubt) but it will likely contain a whole bunch of stuff that when people see it will then say “ahh actually I didn’t mean that”,  “nope now I’ve seen it I probably wouldn’t use that feature”,  “I’m not quite sure how that (feature) works”, “now I’ve seen it I realised there is another feature missing that is far more important”… Which is all good feedback and allows us to iterate through the product development process. I have no problems with that at all.

What I do have a problem with is the muda, the waste. Why build stuff you don’t need, don’t want or doesn’t work?

In contrast if you rapidly and collaboratively sketch out the application in 2 days we get that same feedback 5 and half weeks of 4 developers time earlier and then when we start coding on day 3 we are much more confident that what we are building is not only the right thing for the users, with the right feature set but it also has a cohesive user experience, which is usable and useful.