I just saw this bit of hilarity regarding what if a company were in charge of making stop signs. Funny and accurate as it is, there are nuggets of truth in here about where you can go awry welcoming change.
The reality is, as this so well illustrates, that all change is not good change, and therefore everyone does a disservice to the ultimate customers. By attempting to be a partner and provide ideas within the context of what the user is asking for, the designer enables hasty, uninformed decision making:
- “Lighten it up on the pantone scale” becomes “pink” which seems to meet the customer’s needs.
- Reminding the users about their other demographic eventually becomes make the signs pink and blue.
The reality is, that driving any change based on the whim of your proxy for a customer isn’t a great way to approach a process. Decisions should be based on data about your ultimate customer’s needs (in this case, something clear to the drivers on how to act at intersections). For your product owner to be a good proxy, they must have given enough thought to what your customer desires.
At issue here is not the development process, being Agile would only serve to speed up the implementation of faulty thinking. And sure, going to market fast with a failed design might be quickly fixable, but also might lead to a short lifespan for your product.
Instead, a LEAN development process must extend far beyond the boundaries of actually creating something and into the realm where reasonable thought is given to who your customer is and what they really value before you go making something. And that means making requests that add value, not just requests because your developers are responsive to change. One possibility we seem to fail considering is not just how to take action, but whether we should take any action at all.