Published on <a href="https://blog.prototypr.io/from-let-us-build-to-let-us-understand-and-maybe-build-dce344aa2a30?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Björn <img alt="" src="https://cdn-images-1.medium.com/max/900/1*uT4f05UvZ6s_8lwVq8tzXw.jpeg">
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 thing Krste has found a way!
<a href="https://www.linkedin.com/in/tashonov/">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!
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?
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 — get interested colleagues in a room, brainstorm/report problems in the app and try to find a way to solve each issue.
<img alt="" src="https://cdn-images-1.medium.com/max/900/0*T9AuKn43tcVNj13v.png">
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.
<img alt="" src="https://cdn-images-1.medium.com/max/900/0*LATsriOzn4kTl2Gb.png">
Over the following night I had a thought and the next day I recommended that Krste not solve the issues with high severity and/or frequency. Instead, those issues can be seen as <a href="https://www.producttalk.org/hypothesis-testing/">hypothesis which can be validated</a> with data or qualitative methods. If a hypothesis is true — the issue exists for users and is severe and/or frequent — then work on solving it. If not, spend the time on something else.
<img alt="" src="https://cdn-images-1.medium.com/max/900/0*AwFGjYp6yEaoxRkQ.png">
<h3>From internal ideas to external validation</h3>
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:
<ul>
<li>Issues can take some time to discover — both because they might appear deep in the app content and because they might occur only in edge cases. Giving people a week to report them, instead of brainstorming issues in a single meeting, feels smart.</li>
<li>It’s often difficult to <a href="https://www.producttalk.org/2017/09/compare-and-contrast-decisions/">compare and contrast</a> issues. The severity / frequency graph is a good basis since most issues can be evaluated based on those two dimensions.</li>
<li>An analogue graph that is visible to all eiduers in their everyday life (except our remote colleagues who get other encouragement) can trigger participation.</li>
<li>Instead of trusting our gut and experience to chose what to work on we can validate with actual users whether each issue exist or not, and how severe it is.</li>
<li>It’s good to be open to being wrong. It’s actually great if the issues don’t exist — then we can do something else with our time!</li>
</ul>
Krste is running the process above right now — in the issue collection phase — so we will see how it turns out. It will probably end up being a forth version of the process — but the foundation we have here feels good.
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2Ff51076%3Fas_embed%3Dtrue&amp;url=https%3A%2F%2Fupscri.be%2Ff51076%2F&#038;image=https%3A%2F%2Fe.enpose.co%2F%3Fkey%3DdRXnS9Gplk%26w%3D700%26h%3D425%26url%3Dhttps%253A%252F%252Fupscri.be%252Ff51076%252F%253Fenpose&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a></iframe><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=dce344aa2a30" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/from-let-us-build-to-let-us-understand-and-maybe-build-dce344aa2a30">From ”Let us build” to ”Let us understand (and maybe build)”</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

From ”Let us build” to ”Let us understand (and maybe build)”

Top Stories