Discoverability & Complexity
What's good for the goose...
Sometimes, I think everything is right in the world, and then I discover something is amiss. This does not happen frequently, but it happens enough that I feel compelled to write today.
In several conversations in the past few weeks, I have had this nagging tug that needs addressing. Despite our best efforts, communication remains a struggle at times that limits our understanding and our productivity.
When we develop software, the software engineer tackles a customer problem when developing the software. In many cases, a product manager or UX designer might not yet be in the mix. As that engineer puts features in the software based on their understanding of a feature request, customers can have very different expectations.
In reviewing some of the design drainage software on the market today - I find the vast array of user experience to be fascinating. Recent LinkedIn posts by fellow engineers exploring ChatGPT, the SegementAnything models, or JupyterNotebooks have me wondering where the line is between better tools engineers need to use and well-written software that completes all of this for you. New entrants into the stormwater design market attempting to pull together missing functionality provide a large market with the needed tools. Yet, we still find that most stormwater engineering is done with Microsoft Excel.
I am reading the book The Starfish and the Spider by Ori Brafman and Rod Beckstrom as part of my F3 reading list. It discusses leadership and the “unstoppable power of leaderless organizations,” as the tagline of the book states. Self-organizing groups build powerful organizations that lead these groups without the claim to fame. One of the first examples in the book is the story about how the Spanish were unable to conquer the Apache, as the Apache were able to adapt, and leadership was shared.
A few pages later, there was a discussion of the Internet’s beginnings and how a group of software engineers assembled to build what became Apache to address the problem that the centralized group at the University of Illinois chose to ignore.
Having been swallowed by a large fish, I wonder if the kaleidoscope above will be tackled. This is a crucial benefit of Tuflow; there is no magical mystery tour. The ability to identify key benefits is quickly done without extra effort.
Errors such as this led to a good learning opportunity to change behaviors. However, it has me thinking about discoverability. Short of good training, the action that occurs that results in this error is hard to encourage. A good software package reinforces good behavior, not encourage repetitive stress. Then again, the actual error here reinforces repetitive stress - there is no out, and the conflict always wins.
As a PM - this is a no-brainer - I can not accept my version - so why prompt the user?
How do you balance the discoverability of good behaviors vs. discouraging bad behaviors?
Thank you to whoever developed this! This saved me 56176 mouse clicks.
