As I walked through the office one day recently, I overheard a story kick-off huddle discussing how to implement log-in behaviour. I couldn’t help but cringe as this is a pet hate of mine on multiple levels.
Just having to specify a feature that has such obvious and expected learned user behaviour is annoying as it feels wasteful. It also leads to divergence in the expected behaviour of log-in features the world over, which only confuses users like me.
While listening to this huddle continue about the log-in feature and how it should work, I had a flood of memories of times past, specifying requirements for features such as pagination, exception handling, logging, auditing etc etc etc. Each time I would throw my hands up to the devs and say, “Cmon guys.. you want the business to tell you how you should handle exceptions, or logging and auditing?”. They would give me a confused look, and there I’d be, about to face off and make up some specification on how the feature should work.
I deliberately used the word ‘make up’ because that is what I would do. Without any common reference, I would attempt to provide a complete specification, in some instances within highly technical and specialised domains. Being an ex-developer myself, this came a little easier to me than most, but I would hate to know how a more business focused analyst would feel.
This is the core of my problem, I don’t disagree that specification is required, but leaving it to the last minute just before starting build on a feature, is:
Risky – The necessary expertise for the relevant domain may not be available at this time meaning you get a sub-standard specification that introduces limitations to your system.
Wasteful – You are re-inventing the wheel. These problems were solved a long time ago, and established patterns of behaviour probably already exist and can be re-used.
I had my customary whinge on Twitter, and one of my web producer friends tweeted back a link to the Yahoo Design Pattern Library. She indicated it might help by providing a standardised specification, “[It] doesn’t have bus rules or requirements but covers off best practice interface & interaction”.
On perusal, I discovered the Yahoo Design Pattern Library describes solutions to some common interaction problems. It provides a problem description, a solution pattern and some reasoning and examples. Anyone can submit design patterns to the library, and it seems to be growing slowly but steadily over time.
Putting my BA hat on in the above scenario, I would much rather the discussion centered around ensuring the business need is understood, focusing on things like security risk, user types, technical landscape or sensitivity of data in the system. All these are needs that help inform the solution, and they could possibly be directly mapped to a log-in solution with standard behaviour, rather than settling for a specification that is good enough to move forward into development, but not good enough in the long run.
Although the Yahoo Design Pattern Library is Interaction focused, I think it might be a good place to start. Maybe we could expand it with patterns that focus on the more technical features, for example, an ‘Operationals’ section which would document standard script options defaults, and design principals like “don’t hard-code configuration into scripts”, standard logging levels etc etc..
Or maybe the BA community should come together to develop its own pattern library which would provide descriptions for standardised features which would free us all from this constant specification for features that seem so obvious in their intended behaviour. More to come on this I think…
