Looking back on my journey in conducting research and designing this application, there are several important lessons I’ve learned. In this project, I conducted multiple interviews—ranging from communities that support children with special needs, parents of children with autism, teachers from special schools (particularly for autism), and experts at therapy centers. From these experiences, I felt that my first and second interviews were fairly sensitive to their situations. However, as the sessions went on, I realized how often I struggled to find the right words to use in conversation.

If I were more prepared, with more thorough research beforehand, the results might have been deeper. My lack of preparation before interviewing the parents made me less aware of the vulnerabilities of parents of children with special needs, who often feel misunderstood. This also revealed that I myself did not fully grasp the fundamental differences between children with special needs and children in general.

From this series of interviews, I learned a lot about how to conduct them properly. I came to understand that I need to carry myself differently depending on whom I am speaking with. The way I engage with parents of children with special needs is naturally different from how I should engage with experts, and this realization has been a valuable lesson for me moving forward.

I also observed how others conduct interviews. Some people begin by asking, “What do you need? What do you think will be helpful for you?” At first glance, if I use that one interviewer’s perspective, the question makes sense. However, for me, it was a bit inappropriate to be asked at the beginning. It takes away the essence of an interview. To me, an interview is not just about searching for quick solutions, but about uncovering problems—even ones the participants themselves may not yet realize.

I noticed that many questions often lean toward how to—focusing on solutions. Yet, when we’re discussing pain points, trying to piece problems together, curate them, understand them, or gain a more measurable overview, “how to” questions often feel out of place. What matters more, in my view, is uncovering the thinking process. To bridge the gap between understanding problems and moving toward execution, we need reproducible steps and a solid background.

Of course, asking “how to solve your problem” without really asking it is not easy without experience. That’s why, as a researcher, I believe it’s important to practice reverse questioning and systematic thinking. Every question can be good, but if they all stay linear and keep circling back to the same kind of answers, we risk falling into shallow patterns. Solution-oriented framing questions, on their own, often feel insufficient. My responsibility is to discover answers by exploring all possibilities, not just accept surface-level responses.

This reflection also reminded me of patterns I’ve seen in previous projects. Teams often lacked the drive to dive deeper into the root of the problem. The focus was always more on “how to” and rushing to provide answers right away, as if afraid to truly explore. Yet in many cases, the biggest problems lie deeper beneath the surface.

Another weakness was the lack of observational research. I did not manage to apply an ethnographic approach—directly observing and engaging with children with special needs in their daily lives—which could have offered a richer understanding than interviews alone.

Time was also a big factor. Teams were only given 6 weeks. I understand that deadlines are an unavoidable part of any project, and I write this without blaming time itself. But still, I believe it would have been ideal to have a little more space for research, especially the etnographic research. Extra time could have allowed for more thorough, nuanced findings, and the most important: iterations!

Finally, I realized that I still had an opportunity to iterate on the overall app flow. The new design was ready, the older design was already implemented on the development process, but considering the development timeline in Xcode, I made the trade-off to prioritize meeting the deadline instead. As a result, the new flow iteration—which I personally thought was necessary—was left behind.

This retrospective serves as a reminder that every decision carries consequences. Despite the limitations, I hope this experience will be a stepping stone toward taking more mature, empathetic, and well-directed steps in the future.