Ask HN: As a developer, how do you capture domain knowledge from your users? | Hacker News Reader

Ask HN: As a developer, how do you capture domain knowledge from your users?

12 pointscastdoctor5 comments

As a developer, when working for a client or on your own app, what tools/techniques do you use to capture domain knowledge from your users? For example when using Domain Driven Design, do you use Trello or another board tool to capture commands, queries, events etc...? Most importantly (this is HN after all), what tool would like to have in hand to better capture this knowledge, and how automated should it be? Would you be interested in a tool that captures user needs and builds specs or even an API template, that users could try quickly for rapid feedback?

View on HN

I released a mobile application about ten months ago. By far, I've gotten the best feedback through the feedback feature I built into the app. It's a simple dropdown menu, accessible from any screen, that allows the user to send feedback directly to my email. In addition to this, I talk to my users. These two techniques have given me an overwhelming amount of domain knowledge to build.

Just reaching out and talking to people works wonders and takes almost no effort, so I never had to automate any of it.

Do you use a call to action to let them know its there or to prompt them to use it?

I do not currently use a call to action within the app, but that's a good idea. I'll try it out.

Thanks!

I think the biggest problems are no the lack of a tool to do this, but in the skill in soliciting this information from other people. Especially if those users are on the other side of the world.

To answer your question we use JIRA to capture issues and Confluence to document requirements. But this probably wouldn't be any better than any competing system and is just an organisational choice based on typical business reasons.

Something that I might find useful is a way to link up a "requirement" from a user through to a spec, to design, to code, to the test plan to test it for full tractability. Often we see rules in code and have no idea why that rule is there, but it has to be preserved just in case it was important and was a requirement of the user!

Exploring and debugging the business layer app code end to end and documenting insights or calculation formulae. The next step is to talk to business in case there are bug or feature requests. This is when i can fill in the gaps in my knowledge and sometimes even to confirm if what executes in the code maps with what users intend. I believe beyond tools its a combination of human interaction and the art of debugging. Building an overall picture of the business process and flows is not entirely possible in real world of client support as most of us havent written the code we work with. However, I can say that understanding the business process and the problems being solved by the code is what makes software dev a passion more than a profession and enable us developers to seek the roads to our own entrepreneurial ventures.

Reply on news.ycombinator.com