Month: September 2018

bobwaycott at ycombinator made a comment that summarizes my thoughts on developing software for end users.

Always. I’ve been practicing this for 10 years, most of which I’ve been working as a consultant building custom software for internal business processes, as well as customer-facing software for clients’ users. My typical process looks something like this when a feature/change request or random idea is asked for—which almost always comes in along the lines of, “Can we get X added in that does Y and looks like Z?”:

1. I never say yes to any request immediately. I always tell a client, “Anything is possible that doesn’t violate the laws of physics, but let’s dig into this more.”

2. Ask what they’re trying to accomplish. What problem are they trying to solve? What mistake are they trying to prevent? What is the end goal? I ask questions until I can explain back to the customer what they’re really wanting to do and why.

3. I the push back on why I think we should not do what they’re asking for in the way they’re asking for it. When doing this, I always try educating them on the tech behind the scenes, potential pitfalls, how adding something (especially if it’s visible to people) will make it nearly impossible to ever remove it once users get used to it, when they’re asking for something that would be more effort the way they’re asking for it to be done than it’s worth when it’s trying to solve for a rare edge case, etc.
4. After explaining the problems with their idea as given by non-experts, I start suggesting ways we could accomplish their goals with a simpler UX, or even no UX at all, relying on the ability to automate things if we have enough information, or hide all the complexities of a process behind a single button once we have the right info to intelligently take action.

5. I give a couple of recommendations for potential ways forward that solve the real problem in a way I’ll enjoy building it out. Then I let them make the choice.

Following this pattern has pretty much never failed me. What feels best about it is when I see clients actually learn how their software works when I’m working for them. I love it when they remember the discussions we’ve had, internalized it, and recall it when we talk 6 months later about their new idea. Over time, their ideas improve because their understanding of how their software works improves. They also become increasingly invested in our working relationship as their trust in my concern for solving their problems—and not just doing their bidding—increases.

Never shy away from challenging your customers’ ideas—but always do it in a respectful manner that gets to the heart of their real problems and educated them along the way. They’ll appreciate it, and will keep coming to you for more. I don’t think this is unique to being a consultant, either—the same sort of process can be followed with direct users of your own product