July 8, 2013

...Learn TDD with Codemanship

The Key To Agile UI Design Is User Interface Refactoring

Agile folk have embraced the idea that the first release of a software product is just the start of a very long - potentially endless - journey.

What we can learn from the software we put out there tends to be more valuable than what we guessed at when we were writing it. And for that reason, the best software tends to be much more a product of feedback than of planning.

But it's widely known that this highly iterative approach we call "Agile" has been largely failing us when it comes to the design of the user interface. Our UI's tend towards a sort of Heath-Robinson clunkiness as they grow piecemeal to accommodate rapid shifts in our understanding of what's needed.

This can, and often does, happen under the covers, too. Many Agile teams find themselves hoisted on the petard of 1001 architectural compromises as the design slips and slides from one user requirement to the next.

Unless, of course, they refactor continually and reshape and optimise the internal design as they go. I know a few teams who actually do that. (Gasp!) And they can produce very reliable software with very clean code under the hood that is easy to understand and ready to accommodate more change.

But their UI's... not so much.

I put it to you, dear reader, that this is because we have yet to embrace the concept and the discipline of continuous user interface refactoring.

Yes, there is such a thing as "clean" user interface. User experience has its own organising principles and design heuristics - many of which echo those for internal design (e.g., UI's should be as simple as possible, UI's should be easy for the user to understand, etc). But as we bolt on more and more features, there's a tendency for entropy at the UI level to increase. And so very few teams do on-going work to minimise that entropy. And so, the user interface just keeps getting worse - more complicated, less intuitive, clunkier, less responsive, and so on.

Now, UI design - and it's trendy hipster modern equivalent of "user experience" - is a whole can of worms which I don't want to open here. Suffice to say, there are principles and there are patterns, and if you're minded to, you can investigate them and build your own "school of user interface design" that may suit what you're doing.

Assuming you've established your "school" of UI design, here are three ideas that I've found can help a heck of a lot to steer your UI refactoring:

1. Eat You Own Dog Food

- A comedy basic, but most teams aren't even doing this. When the people writing the software become so divorced from the experience of the end users, expect it to turn out badly. And I'm not just talking about running it through a few simple test cases before you hit the "deploy" button. Actually invest some real time and effort into doing the user's job with your software. It can be a real eye-opener.

2. Make Like The Real World

- I've seen this happen over and over again: teams trial their software in an environment that is nothing like that in which it's going to be used. Hence mobile app developers discover that their software is useless in 80% of the places it's intended to be used, because data connections are too slow, and so on. let's use a hypothetical hotel-finder smartphone app as an example. We think we've design it so that you can find a room within walking distance of where you currently are. The most meaningful to test it would be to send team members out into the Cursed Earth and see how they get on actually finding actual hotel rooms in actual real places, actually. If it's too difficult or expensive or dangerous to test in the real world, simulate it as faithfully as you can. The closer you can get to reality, the more meaningful the feedback it will give you.

3. Users Are Programmers, Too

- Yep, just like in programming. Using a GUI is visual programming, every bit as much as using an API is programming. One of the most useful resources a dev team can have is detailed logs of how their visual programming language is being used. These logs can be analysed to find UI "smells" like over-complexity and duplication of effort, and used as a more formal basis for refactoring the UI to eliminate these smells. In particular, buried in these logs will be groupings of instructions that hint at missing functionality. Since we haven't given them the means to easily express themselves and what they want the computer to do, they may well find a way using the clunkier language we did give them.

Posted 6 days, 2 hours ago on July 8, 2013