
Ask HN: As a developer, how do you capture domain knowledge from your users? - castdoctor
As a developer, when working for a client or on your own app, what tools&#x2F;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?
======
pattrn
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.

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

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

Thanks!

------
bbcbasic
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!

------
parvatzar
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.

