Software Development Practices: What's the Problem?
This is the first post in a series on software development practices. We’re launching the series with a couple of posts aimed at helping those who might not have a technical background communicate their feature requests to developers.
The first time I started working with a development team, I proudly handed them my list of entirely reasonable and helpfully prioritized feature requests and sat back and waited for the magic to happen. They had an unexpectedly large number of follow up questions for me. The conversations went something like this*:
Development manager: We don’t understand this feature request.
Me: It says right there, I need an optional print button on the screen where users edit holdings data.
Development manager: And what exactly should it print?
Me: Ah, good question! It should print the call number, any copy information and, optionally, the location. Thank you for asking.
Development manager: I have a lot more questions, but first, what problem does this solve for the user?
Me: Is this a trick question?
It turns out it wasn’t even remotely a trick question. And so began my gentle schooling in the discipline of articulating problems instead of solutions. I say “gentle” because the developers could have unleashed a barrage of questions at me, including:
- Do you want this on every screen where you can edit holdings data or just a specific one?
- Do you ever want to print multiple records?
- Does the user need a print preview function?
- Does the user need to be able to change the font or font size?
- Are we printing to a standard size, or does that need to be configurable?
Mercifully, they opted instead to encourage me to stop and consider why the user needed to print in the first place. This was a crucial shift in thinking.
As someone who is happily tech adjacent (I like working alongside people who have excellent technical chops, but my talents lie elsewhere), any solution I suggest is going to be based on my understanding of the technology, which is just not as deep or as varied as the technical experts I work with. That means I – or my users – may miss out on a much more elegant solution because I wasn’t aware of all of the possibilities.
I've learned over time that the most valuable piece of information I can share with developers is a good understanding of the problem we’re trying to solve. That sets up an opportunity for me as the workflow expert to partner with the developer and come up with a solution cooperatively. And here’s the best part: most librarians have had at least some exposure to a proven approach for sussing out what problem a user really needs help with. That’s right, dust off those reference interview techniques (See section 3) if you haven’t used them lately – they provide a useful template for identifying what a user actually needs. Here are a few open-ended questions you might want to work through:
- What is the user trying to accomplish?
- What else do I know about this workflow?
- Are there other ways we’ve tried to solve this problem before?
And then some clarifying questions you can think about:
- How often does the user need to do this?
- Do other users do the same activity?
- What are the constraints the user has in this situation?
You can change these up in whatever way works best for you and your project. However you approach it, the better you are able to explain the problem, the better the information you can share with developers and, ultimately, the better the solution for end users. Stay tuned for our next post where we’ll talk about how user stories help you document the problem you’ve identified.
*Specific feature fictionalized to protect the innocent.