How can a user design your feature?

General opinion:

There’s a hyped term — go into the user’s shoes and you’ll make what they would like. Then, you can run campaigns to verify certain hypotheses, take surveys, have interviews, etc. Or see from analytics what could have happened.

Or the best — Once delivered, it’s done. let’s move to the next priorities or tasks. That’s what you’ll see in companies that are just delivering the work. They aren’t mad for their products.

Alternate opinion:

In one line — You’re the feature owner. You own its usage. Otherwise, call it a dead feature.

What do I mean by this?

Here’s an example where users unknowingly helped to design and structure a feature.

One of my colleagues at GreyB recently worked on a feature. For the initial start (after some failure points), even when the feature was TDD-driven and handled all the basic flows. There were 4 edge cases found which could be the ways someone could have entered.

Out of those 4, 3 were fixed except 1 because based on the data present in analytics, no similar case was encountered. As per the TDD principles we let it go (although if done it could have been a quick development of 0.5 days, but wasn’t required).

The Grey Area: Even after testing, many of the scenarios were yet unknown. To tackle this, logs were added. Active tracking of the feature was done when someone used it. As some new/different/breaking flow was found it was handled. The handling was not always adding ifs in the backend but also at times improving the UX.

Developer mindset v/s the real fix: Once one of those 4 edge cases happened. Although it was handled really well, with a detailed informative message for the user at the front end of invalid verification. No, it wasn’t any bug. It was the right flow. One way to deal with this was dropping it since it was the right ideal flow technically.

Another was — To understand the frustration pointers of the user in that flow and debug it further when he got multiple email logs of that user. This is what makes you accountable for the thing you made.

The time it take? 1 day. Within one day, that edge flow took a turn away from the developer mindset handling. Now, the users encounter less blockage within their default flows. This is also how you make your testing what that product needs.

Track the frustrations, you make the feature from the user’s shoes… nah nah… with the user’s brain with not just perceived but real improvements!

Originally published at https://haox.illued.space on February 12, 2024.