(Note: this was originally posted on a since-archived company blog, so apologies for those who’ve read it before)
Architects are never quite sure how their buildings and common spaces are going to be used once real people move in. Just as software developers are never quite sure how their software is going to be used. Architects design openness into their designs in many ways, to allow spaces to be re-configured to a certain extend, and one important idea that they have used is leaving open areas unconstrained so that “desire lines” can form. These represent the most trodden paths, the favourite routes, across a space. Once these have settled down, months after the users have moved in, they can be formalised. Desire lines on grass are reinforced with gravel tracks. Desire lines in offices may be re-carpeted, or defined with furniture.
I’ve seen a few blogs talk about using desire lines to build web sites, using logs to determine which content was most used so that a re-design can highlight those areas or make them easier to use, and reinforce the way users are interacting with the site, but it struck me today when discussing new requirements with a client that desire lines are at the heart of many of the business processes that we model.
It is a rare occasion when a client comes to us with a fully formed idea of everything they want, so design and requirements capture is an intrinsic part of the development process, but there are many areas where the client doesn’t have an idea because no-one has tried it yet. There’s a new business process because they have a new class of user, or new laws to follow, or because the system and the business process it supports are being built together.
It’s tempting, as developers, to look for rigid rules, to find the underlying logic and find ways to make business rules concrete and algorithmic. It can also be the wrong thing to do. Have you ever had a customer or a user complain because the software does the wrong thing? When they have to work around the software to get the job done because the software is too inflexible? Not because the business process is inflexible (there’s not much we can do about red tape), but because the software enforced a business process that was incompatible with the best way to do the job.
Imagine a system where there is an approval process. There’s a screen, with a big “Approve” button on it. We know that the requirements gathering process has identified that there are some business rules that need to be in place before approval. We know for sure that the Approver has to be a different user from the one who started the process, and in order to approve, the user has to add a comment for the audit trail. We believe there should be a time limit, but no-one knows what it should be, we know some other tasks need to be completed, but we’re not sure what. So don’t nail them down. Let the user add the comments to say that the time has elapsed. Let the audit record that the other tasks have been done. In 6 months time, the desire lines will be obvious. There will be a process. That’s when you update the screen.
We’re not mind readers or fortune tellers, so when we find ourselves looking at a problem we’re trying to nail down business rules that don’t quite make sense, or aren’t quite firm enough, maybe it’s time to step back and see if there’s a way to let users define their own desire lines where they get to decide how to get the job done, and once they understand the rules, we can always enforce them in the next version.