The elevator panel in my apartment lobby is slightly unusual. It has up and down arrows, as one would expect, but it also has a third button labeled “Dog Run”. This button often makes visitors momentarily hesitate as they reach for the panel.
|Dog Run Button:
Keep reading if you don’t know what this button does.
Every day, when I look at this elevator panel, it reminds me that even the most trivial features come with costs. The cost of one additional button may not be readily apparent. But imagine an elevator panel that includes dozens, or perhaps hundreds, of specialized buttons. A panel like this might be completely counter-intuitive and maybe even unusable.
Knowing what I know about the dog run button’s purpose, I’m sure that it’s exactly where it needs to be. However, I often wonder about the thought process that went into its design:
- What need was this feature designed to address?
- Was that need worth addressing?
- If so, is this the optimal implementation?
Below, I’ll shed some light on how we analyze enhancement requests, especially in the context of the three questions mentioned above. My reason for doing this is simple: I want to reassure users that their suggestions don’t disappear into a void. I also want to encourage users to continue to participate in the brainstorm and help us keep the pace of innovation on fire.
The Root Issue
In the same manner, when a product enhancement is suggested, we don’t usually jump to implementation. Instead, we examine the root issue first.
We typically find that each enhancement request is actually a request for a solution to an issue encountered by the user. An examination often reveals the root issue to be one of the following:
- A defect that needs to be fixed
- A need that the user doesn’t know the product already addresses
- A need that the product doesn’t address
Here’s a real example. During the beta phase of ADL, a user suggested that we introduce the ability to automatically launch an algorithm when the market opens. Upon further interview, we discovered that the user had previously attempted to launch his algo during the pre-open, only to have it pause immediately. As a result, he resorted to manually launching his algo right at the open to gain place-in-queue, and he was looking to automate this manual action.
The root issue here was that all algos were designed to pause during untradable market states (e.g. closed, closing auction, expired, post trading, freeze etc.). What the trader really needed was a way to operate an algo outside of tradable market states. To satisfy this need, we ended up introducing the “Ignore Market State” functionality and the Market State Block.
This was a case where we decided to address the trader’s need. However, that is not always the case – every identified need begs the question: “Is the need worth addressing?”
Scope of the Product
Some users may conclude that their business needs lie outside of ADL’s scope. I recognize and respect this decision. In fact, I believe focused scope benefits the prospective user; the more focused the product, the easier it is for a user to determine whether or not a product meets his/her needs.
When ADL fits a user’s needs, its focused scope translates into a superior user experience with a product that is highly performant, intuitive and effective.
As ADL matures, we plan to gradually expand the scope to accommodate the usage of technical indicators and fundamental data. However, proficiency will always be prioritized before expansion.
Implementation: Tools, Not Options
The core “less is more” principle behind ADL’s implementation is self-evident in the product itself: ADL is a streamlined toolbox of blocks, not a giant collection of checkboxes and drop-down menus.
Look at the image below. I call this the “learning curve vs. flexibility” spectrum. Generally speaking, hard-coded options, such as drop-down menus and checkboxes, lie on the left; they are probably the easiest to use, but also limited in flexibility. APIs are placed on the right; they probably have steep learning curves, but are also very flexible.
When this principle is applied, the final implementation may end up looking nothing like the original enhancement request, even if it fully addresses the user’s need.
Back to Dog Run…
Applying the principles mentioned above, it seems that this button was a downstream effect of an architectural limitation (apparently only one elevator can stop at the second floor) combined with the residents’ need to use the elevator to reach the second floor (apparently residents can’t or won’t use the stairs). Going further upstream, the root cause seems to be the residents’ need to walk their dogs indoors. I don’t own any pets, but it is my humble opinion that owners should walk their dogs outside in the first place…yes, even during Chicago winters. With that said, the indoor area seems like a superfluous feature that can be removed along with the “Dog Run” button.
While I hope I entertained you with my analysis of the dog run button, I hope even more that you gained an understanding of how your ideas and feedback fuel the processes that drive ADL’s evolution. If you’re an ADL user, I hope I’ve inspired you to contribute (or continue contributing) to the innovation of ADL.