Before you start coding, you usually need to clearly define what needs to be built. In other words, you take unclear requirements and turn them into actual features based on what you hear from your client, senior developer, or designer.
I started my career in a small company, and in many small companies, the development process is not well systemized. (I'm in Korea.)
In my case, I often didn't receive proper feature specification documents, and sometimes there were no API documents at all.
Because of that, I had to take responsibility for clarifying the requirements myself. I would summarize the feature requirements, write them down in my own words, and then go back to confirm whether my understanding was correct.
This process helped me avoid misunderstandings and reduce unnecessary rework during development.
Regardless of company size, clear documentation is essential. When it's properly shared and used across the team, it helps reduce unnecessary communication and meetings.
Recently, I did some additional work for a previous company.
The requirements were mainly about user verification use cases.
My boss was not a developer and didn't have much knowledge of programming. Because of that, the requirements were often quite messy and not clearly defined, so I had to put effort into organizing and structuring them myself.
Our app had multiple user statuses, such as guest, blocked user, and pending user. However, communication between the backend and frontend was not very clear, which made things more complicated.
To solve this, I broke down the user verification flow into clearly defined statuses and documented them. For example:
*** Non-member**
guest: active && none (no authentication)
*** Member **
user: pending && not_submitted (just signed up)
user: pending && submitted (documents submitted to admin)
user: active && approved (approved by admin)
user: pending && rejected (rejected by admin)
To make sure my understanding was correct, I created a Confluence document based on this.
It worked as a shared reference for everyone involved - my boss could verify that each use case matched what he had in mind, and the backend developer could confirm whether the status values he was returning were correct.
Another thing I liked was that whenever requirements changed or something new was added, we could just update that one document. No more back-and-forth messages trying to remember what we agreed on.
One doc, three people, way less confusion.
SOCIAL SHARE CARD GENERATOR