{"id":2759,"date":"2018-09-11T10:38:02","date_gmt":"2018-09-11T17:38:02","guid":{"rendered":"http:\/\/www.wellgolly.com\/?p=2759"},"modified":"2018-09-11T10:38:02","modified_gmt":"2018-09-11T17:38:02","slug":"understanding-user-requests","status":"publish","type":"post","link":"https:\/\/www.wellgolly.com\/?p=2759","title":{"rendered":"Understanding User Requests"},"content":{"rendered":"

bobwaycott<\/a> at ycombinator made a comment that summarizes my thoughts on developing software for end users.<\/p>\n

Always. I\u2019ve been practicing this for 10 years, most of which I\u2019ve been working as a consultant building custom software for internal business processes, as well as customer-facing software for clients\u2019 users. My typical process looks something like this when a feature\/change request or random idea is asked for\u2014which almost always comes in along the lines of, \u201cCan we get X added in that does Y and looks like Z?\u201d:<\/p>\n

1. I never say yes to any request immediately. I always tell a client, \u201cAnything is possible that doesn\u2019t violate the laws of physics, but let\u2019s dig into this more.\u201d<\/p>\n

2. Ask what they\u2019re 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\u2019re really wanting to do and why.<\/p>\n

3. I the push back on why I think we should not do what they\u2019re asking for in the way they\u2019re 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\u2019s visible to people) will make it nearly impossible to ever remove it once users get used to it, when they\u2019re asking for something that would be more effort the way they\u2019re asking for it to be done than it\u2019s worth when it\u2019s trying to solve for a rare edge case, etc.
\n4. 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.<\/p>\n

5. I give a couple of recommendations for potential ways forward that solve the real problem in a way I\u2019ll enjoy building it out. Then I let them make the choice.<\/p>\n

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\u2019m working for them. I love it when they remember the discussions we\u2019ve 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\u2014and not just doing their bidding\u2014increases.<\/p>\n

Never shy away from challenging your customers\u2019 ideas\u2014but always do it in a respectful manner that gets to the heart of their real problems and educated them along the way. They\u2019ll appreciate it, and will keep coming to you for more. I don\u2019t think this is unique to being a consultant, either\u2014the same sort of process can be followed with direct users of your own product<\/p>\n","protected":false},"excerpt":{"rendered":"

bobwaycott at ycombinator made a comment that summarizes my thoughts on developing software for end users. Always. I\u2019ve been practicing this for 10 years, most of which I\u2019ve been working as a consultant building custom software for internal business processes, as well as customer-facing software for clients\u2019 users. My typical process looks something like this … Continue reading Understanding User Requests<\/span><\/a><\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-2759","post","type-post","status-publish","format-standard","hentry","category-coding"],"_links":{"self":[{"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=\/wp\/v2\/posts\/2759","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2759"}],"version-history":[{"count":1,"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=\/wp\/v2\/posts\/2759\/revisions"}],"predecessor-version":[{"id":2761,"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=\/wp\/v2\/posts\/2759\/revisions\/2761"}],"wp:attachment":[{"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2759"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2759"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wellgolly.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2759"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}