Design simplicity and the trouble with requirements.
I design products are either highly involved with the user interface on consumer devices or designing web portals that sell consumer media products, and I keep coming up against requirements wars.
The problem that I had with “requirements” was it was always less risky to add to them than to remove them. Political business people who did not care for the consumer user experience would often pile in a whole shed load of requirements that in some way benefited their department (sometimes this was just to halt development till their department could publicise a rival solution)
Inexperienced product managers and marketing people who were uncertain about user behaviour would always add bells and whistles till the original product concept was hidden in a miasma of crap
The result was always the same;
A requirements document that was compromised, with no design simplicity.
This often resulted in commercial failures, and blots the good name of my development.
Where as … the things that we “just did” and that managed to get highlevel backing often made headlines and were always met by rave reviews.
Agile offered me mild relief, as I could control scope or even back out of committing to products that were clearly plagued by too many stakeholders and requirement bloat, and I could do this even after development had started
The problem is that someone who is seeking to mitigate risks will see a small requirements set as a risk, where as this is not compatible with reality. Design simplicity is a great way to reduce risk, it is also a great way to make “nice to use” products.
My belief is not that it was the process of requirements gathering or the format of the requirements that causes the problem, as I over a number of years I changed this again and again trying to improve the number of hit products.
What I want to be able to understand is how the traditional requirements gathering procedure is compatible with increasing the risk so that a company can be commercially competitive?
A happy motivated company that is making good products operates at the highest comfortable level of risk.
The solution is … don’t have the traditional approach to requirements, make a list if you like but certainly don’t use it as your major design document. Instead make a diagram or picture or animation or movie or podcast or wiki or even code – any thing that best expresses the essence of the design
0COMMENTS