One of the challenges of project work is that you have to get into things quickly and without much help – in many places, people will have neither the time nor the inclination to teach you.

Remember that if you want to write about how something works, you have to understand the why of it as well. Users have to be given a context in which to work, a logical explanation to why things have to be done a certain way. It makes it easier for them to remember, and it removes the frustration users experience when they think an application is making them work hard for no real reason. So it’s not enough just to figure out the UI to stay one step ahead of the user – you have to really understand what’s happening.

First, learn a little bit about the field you’ll be working in. You should be able to get a basic understanding of it on your own before you ever touch the application. Then the application itself will make enough sense that you’ll be able to start using it, and it will become a source of intelligent questions.

At this point, you’ll be learning about the application (by using it) and the field (by asking questions based on the application) at the same time. These learning points correspond to the how and why you’re looking for: how does the application do something, and why is it needed and done in this way.

The application obviously teaches you about the field by revealing options and concerns you hadn’t seen in your previous research. But the field research can also teach you about the application: it will lead you to search for specific abilities and combinations that you might have missed if you’d just gone blundering around the UI clicking buttons. It will also help you define the limits of the application.

Something you’ll need a little help learning but which should save you a lot of time later on is an understanding of the system architecture and implementation. For example, you’ll find definitions easier to understand if you know which of them affect locally and which affect something on the server. But don’t let this be the first step – architecture and implementation are easier to grasp when you have a little application familiarity to help tie things together.

If you know how to use debugging tools, logs, sniffers and databases you can make things easier for yourself by following the processes behind the scenes. You’ll not only learn a lot, you can also simulate hard-to-reach states to see what they look like. For example, if you want to see how old information is displayed, you can manually enter information with old date-stamps.

By now, the application should be fairly clear to you. It’s time to start clicking buttons – all the buttons – to see what happens. Go crazy, and make careful notes of interesting states you’ve reached. These will be a goldmine when you start writing your guide.