I've been away on customer visits so I've been immersed in a world that's rather different than the usual environment. It's been a really valuable experience, but I haven't been able to step back much and contemplate things let alone write here. However, now that I'm back, I've had some time to think through the discussions I've had with my customers recently.
Normally I have relatively little contact directly with customers. I may hear their filtered input through other teams which are more customer-facing, but I normally focus most of my time in back-to-back-to-back meetings with colleagues. While that can be good to get things done, it also means that we can lose track of what we're truly putting in front of our customers.
Sitting in the same room with customers while they use our tool and show their frustration is an unsettling experience to say the least. I expect to hear complaints about gaps or bugs in functionality, but the really startling part is when I see how complex we make things for our customers. More often than not, this complexity is due to "flexibility" we want to give our customers. And it's ever more clear to me that adding features or settings or preferences in the name of flexibility is not always a good thing. In fact, unless there's a lot of thought put into those additions, they can, more often than not, be a BAD thing!
We may think the tough decision is about committing to adding more features. In fact, the toughest decision can be about paring down features and making things more simple. The proverbial "more with less" definitely applies to web applications. Our application has a hidden preference to auto-correct specific errors when building an order. It's a great feature, but it's not turned on by default, and we have to tell users in training materials why it's a good thing and how they should turn it on and off. So not only do users need to worry about whether this great feature is on or off, we spend more time telling them about it basically just telling them to turn it on! I'd contend that feature should be blind to the user. Just turn it on and tell the users about what we've fixed in the background, but only when they want to see the details.
This sort of thing has been written about quite a bit so I won't be-labor the point. I'm just reconfirming that, yeah, trying to simplify your end-product is a good goal and the work involved in simplifying can be way more difficult than the work involved to endlessly add more features.
I'll leave you with an article a friend sent over to me recently. It's about constraints and forcing ourselves to make tough decisions: Constraints
Normally I have relatively little contact directly with customers. I may hear their filtered input through other teams which are more customer-facing, but I normally focus most of my time in back-to-back-to-back meetings with colleagues. While that can be good to get things done, it also means that we can lose track of what we're truly putting in front of our customers.
Sitting in the same room with customers while they use our tool and show their frustration is an unsettling experience to say the least. I expect to hear complaints about gaps or bugs in functionality, but the really startling part is when I see how complex we make things for our customers. More often than not, this complexity is due to "flexibility" we want to give our customers. And it's ever more clear to me that adding features or settings or preferences in the name of flexibility is not always a good thing. In fact, unless there's a lot of thought put into those additions, they can, more often than not, be a BAD thing!
We may think the tough decision is about committing to adding more features. In fact, the toughest decision can be about paring down features and making things more simple. The proverbial "more with less" definitely applies to web applications. Our application has a hidden preference to auto-correct specific errors when building an order. It's a great feature, but it's not turned on by default, and we have to tell users in training materials why it's a good thing and how they should turn it on and off. So not only do users need to worry about whether this great feature is on or off, we spend more time telling them about it basically just telling them to turn it on! I'd contend that feature should be blind to the user. Just turn it on and tell the users about what we've fixed in the background, but only when they want to see the details.
This sort of thing has been written about quite a bit so I won't be-labor the point. I'm just reconfirming that, yeah, trying to simplify your end-product is a good goal and the work involved in simplifying can be way more difficult than the work involved to endlessly add more features.
I'll leave you with an article a friend sent over to me recently. It's about constraints and forcing ourselves to make tough decisions: Constraints
