1. Introduction
The process of delivering a single screen to the user involves more steps than expected. It seamlessly connects the stages from planning, publishing requests, development, to testing. This time, I took on most of the process, excluding publishing, myself.
This article reflects on the process rather than introducing the final product. It aims to organize my thoughts on the concerns I had while experiencing a complete cycle, where I faced challenges, and what improvements can be made next time.
2. Planning - From the User's Perspective, Not the Developer's
The main concern during the planning phase was the user's usage flow. While developing, there are times when it naturally leans towards simpler implementation perspectives. However, I aimed to first consider what actions the user would actually repeat.
A representative example was the feature to change item status in a list. From a development perspective, it is simplest to click a row to navigate to the detail screen, modify the value, and then save. This structure is clear, and the implementation difficulty is low.
However, considering the actual usage scenario, users often needed to quickly modify the status while checking several items. The approach of navigating back and forth to the detail screen led to unnecessary clicks and screen transitions as the number of items increased.
Thus, we chose an inline editing method that allows the status to be modified directly from the list screen. The implementation process required additional work such as row-level state management, recovery processing in case of save failures, and optimistic updates. Although the development effort increased, it reduced the tasks users needed to repeatedly perform.
Of course, not all decision-making can be based only on user convenience. Realistic constraints such as schedules and resources also exist. However, I felt it was important to clearly recognize the reason behind any choice made. Whether it was a choice made at the cost of user experience or a compromise due to scheduling, distinguishing this is crucial for clarifying future improvement directions.
3. Publishing Request - What Matters More Than Delivery is Clarity
The stage where I learned the most during this cycle was the publishing request process. Although a dedicated team handled publishing itself, my role was not just to pass the work but to organize it into a state where the other party could start working.
At first, I thought it would be sufficient to explain the features and structure of the screen. However, during the actual collaboration, the information I took for granted often was not the same for the other party. If the conditions for the screen's state, operational methods, and exceptions are unclear, additional discussions and modifications naturally arise.
Another insight was the importance of sufficient consensus before starting the work. Since each person may have a slightly different image of the screen in mind, if we don't align on this beforehand, the cost of readjustment after the work can be significantly higher than expected.
Ultimately, the publishing request was not just a simple transfer task. The clarity with which I could organize and share my understanding greatly influenced the efficiency of collaboration. Through this experience, I realized that many issues arising in collaboration might stem not from the ability to do the work but from information transfer problems.
In the future, I expect to spend more time organizing things once again before making a work request and confirming whether the other party has the same vision.
4. Development - The more prepared you are, the simpler it becomes
During this task, the development phase proceeded without much difficulty. I handled both the backend and frontend directly, and there weren't many unexpected obstacles.
At first, I didn't think much about the reasons, but looking back, the reason development was smooth was that a certain direction had been organized in the earlier stages. What was to be created, the state of the screens, and how users would interact with the functionalities were relatively clear. Thanks to this, during the development process, I could focus on implementing already organized content rather than making new decisions.
Being responsible for both the frontend and backend also helped. Generally, it's necessary to adjust the API interface and data structure, but this time I could work with a single flow. I was able to design the API considering the needed formats from the frontend, and conversely, I could implement the screens while understanding the backend structure.
Through this experience, I realized once again that the difficulty of development is not only determined at the moment of writing code. How much thought and organization was put into the earlier stages greatly influenced the complexity of the subsequent development process. This task made me reflect more on why it could be easy rather than just the fact that it was easy.
When looking for related cases, I found it impressive that some teams invest more time in design and screen definitions than in development. While it may seem that the development speed is slow at first, it actually reduces the modification costs at the implementation stage, thus shortening the overall lead time.
As I worked on this task, I gained some understanding of why such an approach is chosen. The reason why the development phase could proceed quickly was also due to many decisions being made in the earlier stages rather than during the implementation process.
5. Testing - The last stage that was less than expected
The stage that left the most regret was testing.
This time, I did not write separate test codes and conducted the review by directly checking the completed screens. This was a method that was sufficiently possible in a situation with not many functions, and I was able to finish without any major issues.
However, looking back after completing the work, I thought that testing heavily relied on human memory. As screens increase and revisions are repeated, there are continued instances where previously checked functionalities need to be re-evaluated. It's manageable right now, but it seems difficult to maintain the same method as the scale grows.
In particular, while I naturally check normal screen flows, I also felt that exceptional cases, such as situations without data or when errors occur, are relatively easy to overlook. I thought that I had considered such states during the development process, but in the actual review stage, I tend to focus on normal scenarios.
While organizing the retrospectives, I also looked into the testing methods of other teams. It seemed that rather than managing all functionalities with test codes, it is surprisingly common to automate only the core flows that users use most frequently and to combine them with manual review for the rest. Especially, it was impressive to see cases where only major scenarios are validated through E2E testing, or where the state of screens is managed using Storybook.
While this may still be an early choice relative to the current scale of the project, I felt that it was worth considering if the workload of repetitive reviews increases. Rather than changing everything at once, it seems more realistic to gradually add small safety measures to the current methods.
6. Conclusion
The most significant aspect of this task was the opportunity to experience the entire process of delivering a screen to the user from start to finish.
Previously, I thought of planning, publishing, development, and testing as independent stages. However, going through the entire process made me realize how strongly interconnected each stage is. The material organized in the previous stage made the next stage easier, while ambiguities returned with greater cost as we progressed.
I also had the chance to think from the perspective of different roles. Instead of just being in a position to send requests and receive results, I gained a little understanding of what information is needed and where difficulties arise. Thanks to this, I learned a lot about what needs to be prepared more in the collaboration process.
This retrospective is more of a record of the process than a record of the final product. While what was created is important, experiencing the process of how it was made was the greater gain. Next time, I would like to improve upon the shortcomings discovered this time and create a better cycle little by little.
jun