{"id":1038,"date":"2017-10-31T00:34:42","date_gmt":"2017-10-30T22:34:42","guid":{"rendered":"https:\/\/www.neovita.com\/thoughts\/?p=1038"},"modified":"2017-10-31T06:08:06","modified_gmt":"2017-10-31T04:08:06","slug":"from-lets-build-to-lets-understand-and-maybe-build","status":"publish","type":"post","link":"https:\/\/www.oninteractions.com\/thoughts\/from-lets-build-to-lets-understand-and-maybe-build\/","title":{"rendered":"From \u201dLet us build\u201d to \u201dLet us understand (and maybe build)\u201d"},"content":{"rendered":"

Sometimes a project is started based on a feeling that a designer, engineer or manager has. However, what we choose to build should be “directed” by our users. Is there a way of getting user driven in a project that started based on internal feelings? I think Krste has found a way!<\/strong><\/p>\n

Krste<\/a>, one of the developers at Eidu, had experienced problems in the Eidu math app. The interface was not responding as it should and some feedback was missing. It was time to fix it!<\/p>\n

At Eidu each employee can choose what to work on and after understanding that other eiduers felt similarly, a project was born with the goal of removing annoyances from the app. But which annoyances?<\/p>\n

The goal was formulated during a strategy week in which I encouraged my colleagues to understand the problem space, then ideate together via brainstorming and choose goals by quite generic reasoning. Krste had the idea of doing something similar now \u2013 get interested colleagues in a room, brainstorm\/report problems in the app and try to find a way to solve each issue.<\/p>\n

\"\"<\/p>\n

However, as I and Krste discussed the plan, Krste came up with something that I think is much better: Encourage all eiduers to report problems over the course of a week. Have us all describe the issues including who is likely to experience them (kids, teachers, parents, eiduers) and place them in a graph with frequency on one axis and severity on the other. And have the graph on a whiteboard in the kitchen area of the office. At the end of the week, have us all come together to understand the problems and discuss if they should change position within the graph. Then solve the most frequent and\/or severe problems.<\/p>\n

\"\"<\/p>\n

Over the following night I had a thought and the next day I recommended that Krste not<\/em> solve the issues with high severity and\/or frequency. Instead, those issues can be seen as hypothesis which can be validated<\/a> with data or qualitative methods. If a hypothesis is true \u2013 the issue exists for users and is severe and\/or frequent \u2013 then work on solving it. If not, spend the time on something else.<\/p>\n

\"\"<\/p>\n

From internal ideas to external validation<\/h2>\n

It is slightly wonky to start a project with the goal of “solving some problems”. However, now that Krste want to do a “quality upgrade” of the app, I think the above steps have great potential:<\/p>\n