I joined a project team at Kuaishou to make application that facilitate 30k employees to optimize their working efficiency by creating solutions for their network problem; the project is named “network diagnosed and report application”.
Usually, a projects proceeds as finding out a need, proposes a solution, and highlighting the value of the solution. However, this project has already begun and the user requirement documents were created when I joined. I received a technical document as the only item, and been told to design and implement this application. Given the ambiguity, I have to reverse-engineering what problems this application is trying to resolve and what value can it capture. I went ahead to develop the API and design the ER-diagram for the data that we potentially wanted to store. I gradually figured out the users requirement and the incentive by processing unstructured data such as the technical document and conversation with my product manager and my supervisor in the team. Later, I was given the user requirement document and trying to get familiar with the framework that the team was using which contains multiple layers in a MVP fashion. As I was developing, there are some back and forth adjustment code fixes when I deal with testing and frontend team. We are even still fuzzy on the logic of this application which contains two situations, one is more complicate but allows users to specify the problem with more details, the other which is convenient and brief for users. The first one connects with a technician remotely and pulls a group chat to troubleshoot with users online; and the latter one, users only need to sit back and wait the technician come to deal with the computer for you.
It makes me ponder what the value this project captures and led me to re-construct user persona. It turns out the reason that we have two options isn’t only about giving the option to skip complicate forms to describe the problem, or telling the technician how urgent the case is. It is simply what values of the application can match with the behaviour and traits of that customer. People is proficient with computer tend to be pleased and capable of describing issues of their computer. On the other hand, having someone who can take care the computer for the other half of the population is doing a tremendous favour for them.
中文版：
我加入了快手的一个项目团队，负责开发一个应用程序，该应用旨在帮助3万名员工通过为其网络问题提供解决方案来优化工作效率。这个项目名为“网络诊断与报告应用”。
通常，一个项目的流程是先发现需求，提出解决方案，并突出解决方案的价值。然而，当我加入时，这个项目已经开始，并且用户需求文档已经创建。我收到的唯一资料是一份技术文档，并被告知要设计和实现这个应用程序。由于信息模糊，我不得不通过逆向工程的方式来推测这个应用程序试图解决的问题以及它能带来的价值。我着手开发API，并设计了潜在需要存储的数据的ER图。在这个过程中，我逐渐通过处理非结构化数据，如技术文档，以及与产品经理和团队主管的对话，理清了用户需求和项目的动机。后来，我拿到了用户需求文档，并开始熟悉团队使用的包含多层MVP模型的框架。在开发过程中，随着测试和前端团队的协作，不断进行了代码调整和修复。即便如此，我们对应用的逻辑仍有些模糊，该逻辑包含两种情况：一种更为复杂，允许用户更详细地描述问题；另一种则简便快捷，用户只需等待技术人员来处理问题。复杂模式下，用户可以远程连接技术人员，并创建群聊在线排查问题；而简便模式下，用户只需静待技术人员上门处理。这让我重新思考这个项目给目标用户带来的价值，并让我重新构造了用户画像。
最终，我们发现提供两种选择的原因不仅仅是为了让用户跳过复杂的表单填写，或者告诉技术人员案件的紧急程度。这实际上是为了匹配应用的价值与客户的行为和特征。那些对计算机较为精通的人更倾向于详细描述他们遇到的问题，而另一部分用户则会更愿意让专业人员直接处理问题，这对他们来说是一个巨大的帮助。