This past summer I worked on an internal tool at a medium-sized software company. I was told what the tool was for and which features I needed to add to the tool. I went through a short design process – namely, I worked with my manager to write out a design document where I described potential versions of how required features would look and how I would implement those required features. At no point in the design process did I frame the tool I was building in terms of the end user.
Because I was working on an internal tool, I often interacted with engineers who used the tool I was expanding upon, but I did not think about the features I was building in terms of the customer. I was more focused on doing what I was told to do in the best (fastest, most aesthetic) way possible. Near the end of my project, I actually did a user study with engineers where I learned more about how the engineers actually used the tool. I learned A LOT from the process of actually talking with people – in fact, I learned that there were essential pieces of information that I had entirely left out of my design, simply because I never thought to ask the end user what they needed. Going forward, I plan to be much more intentional about framing projects with the end user in mind. User stories are incredibly powerful, as they force engineers to actively consider the end user and maybe even speak with the end user in order to understand what requirements need to be implemented and why.
Certainly it’s important to write out what requirements will look like and how they will ultimately be implemented, but it’s difficult to actually understand how requirements should look and be implemented without considering the end user.
