Sometimes being a usability guy can be a bit straining on one's sanity, especially since most of the business world as we know it think usability is something about a pretty user interface. And this usability guy also happens to enjoy small iterative development steps, somewhat agile programming styles, and a fetish for change.

Change

With any organisation comes a fear of change; fear of something new, fear of something they don't master, and the fear to move forward or backwards without sufficient control. But of course, with all that control (or want for control of that which they don't know) in place we're pretty much standing still. Change comes usually through individual push from people who just do things (often acommidated by 'That's it! I've had it!') , and not as much through memos and policy documents, even though the board might think their changes are radical.

My whole life I've been one of those who embrace change, always tinkering and changing stuff, trying to find better ways of doing things. It hasn't been easy; what I thought was natural to us all seems to be unnatural for most. The holistic viewer is rare. Too many castles, too many counties and countries, too little planet and far too little universe.

It is said that things change best by taking baby-steps. I'd rather say you need to take large baby-steps.

Time

Estimating how long a piece of string is, is one of those things most people get wrong. So, I don't do that. You see, a while back I discovered that the more important the project, the bigger it was and the more cast in iron things were (from specs to time-lines), the more spectaculary it would fail. I'm sure you've noticed too. I'm sure we've all been in a fair number of them.

One way I deal with this problem is to break the problem up into smaller bits and user-test each bit, so instead of trying to pull off 10 things in the span of 10 months and give it a big test a week before it's supposed to be ready, I do 1 thing per month, test that part and take it from there. Seasoned project managers tend to hate my way, because it is hard to measure by text-book project management books and methodologies, and people have a tendency to think they think holistically about problem-solving. But what they actually think is far too often far from the truth.

If the plan is to have 10 things done in the span of a 10 month project, what usually happens? We break them down into sizeable chunks, assigns the subtasks, and try to manage it so that in 10 months we get what we said we would get. If we're late or early, this can easily be seen in project plans and reports, and all is well in the world, because this is the theory.

Along comes real-life; we're three months into the projects, and programmer A with part Z tries to plug his part into programmer B's fancy XY framework, and fails miserably. Communication hasn't been bad, and they've all written buckets of programming style guides and written JavaDoc and technical documentation. And yet the bits didn't fit. This only marks the beginning of the failures of the project, and when you're 20 months overtime you've got a half-baked compromised and limping version of some idea that by this time ain't no longer what you want.

Teamwork

So what should have happened? Well, let's pretend we've got 5 developers and 10 tasks to finish over 10 months. The text-book would state to give each developer 2 tasks. And the answer is of course 'no'; try sitting your 5 developers down to solve one problem. And not one problem each; everybody solve the same one problem. Once that's been solved, you can happily move on to the next problem, because here is what you've got through the process; a finished and tested part, ready to be built on.

Some think that this approach wastes a lot of time for some of developers that could be well spent on other problems, but you see, this is the part where their claimed holistic thinking clearly is flawed; individuals can't be holistic in isolation. No matter how much you try to create a middle layer of communications, nothing beats hands-on experience. Nothing. And if you get everyone up to speed on the one thing, they don't need to be told what that thing is during the next step.

Some say that even this way of doing it is flawed, because they can spend 3 months on getting that one thing right. The answer is obvious; if your developers can't pull off one good thing in time, how do you think they'll fare in multiple things? And also consider how you plan these things; if it indeed takes three months, you've done a bad job of breaking the problem down, my friend. There is nothing wrong with calling a part of your system for an API, or a widget, or an application, or a service. Break it all down into looser reusable bits, because not only is it more managable but project 2 and 3 can now simply reuse that service or API or widget, build on them, extend them, and also strengthen project 1. That's being holistic; break things apart, and put it back together again in clever ways.

Your team

Ok, so everybody needs to be on the same level, and sure, a HTML markup guy won't understand all the geeky finesses the hardcore Java developer does, but here's the thing; if the Java developer can't explain it so that the other person do understand it, it is a failed part. I don't care if you think it is so darn clever and I'm so stupid; at some point, others must understand, and if the lowest common denominator can't understand it (to some satisfactory level of 'understanding') then start again (or, in extreme cases, get rid of that developer; you're not creating a hot apple pie with bad apples, are you?). Tweak it until everybody is on the same level of understanding, because - and here is another important thing - you might be wrong. How about that.

Yes, a big part of usable thinking is to test the darn thing all the time; developers, project managers, business owners and - perhaps somewhat shocking and unusual to some - the actual users. And we do this because the business requirements might be dumb or wrong, and they need to change. Embrace change, change is good. If we don't embrace change, we'll go back to our text-book project at the fifth month when a business case change and we need to change not only all the parts that's affected, but all future plans and prospects as well. This last bit is vital in creating great systems; don't plan for something that might not be a great outcome.

Testing

Doing test cases for our software development seems to be paramount these days; we create test cases, and we develop software that solves the problems described in the test cases until they're solving all of them.

Why hasn't this approach been embraced in other places? When a business owner writes down a business requirement and pass them off as a systems requirement, why isn't this tested? Cross-checking with the sponsors and project management isn't good enough; you need to tap into your users and pull those wisdomteeth out; does this business requirement even affect what the user want? Very often you'll hear in usability tests 'all I really wanted to do is ...' It would have been far cheaper to hear that statement before the business ideas became business requirements than close to release date.

Look to a lot of the big boys of software development these days; they release alpha software for people to play with, beta versions for people to test, and give away parts of their core tools because, in time, it will come back and help them far better than any closed "it will be a big surprise!" plan will ever get you. It is all about testing; testing for bugs, testing for features, testing the interface, testing the market, and, some times, testing the sanity of the business owners; they just might be wrong. Imagine that.

Permalink (Tue, 17 May 2005 13:00:00 GMT)| Comments (0) | Interface and interaction design