We begin our design challenge once we identify our archetype persona and its problems and needs.
Once here, we use the HMW technique (How might we…?) in order to define our objective, identifying actions, users and expected results. It was about doing a divergence exercise, in which each of us would define every of these components, and which would conclude with convergence, since we voted for the ones that most convinced us.
Finally, we decided to group the three HMWs into one:
How could we get people to participate without investing a big amount of their time, fostering a sense of community and obtaining results?
This is the goal that we have always had in mind when defining our solution.
We use this technique to devise in a more detailed way what our solution idea would be like.
After an exercise of divergence, we presented the ideas that each of us had had. We ended up converging, making the decision to group the four ideas into one. The result was the following:
It is an app that, using geolocation, allows the user to mark or indicate the needs, flaws or improvements in their neighborhood. You can indicate which categories interest you in order to participate and join existing proposals and even create them. The most voted or followed initiatives will be communicated to the institutions publicly (eg, via Twitter, sending them to the relevant district boards) and also to users.
Users will only receive the information about their neighborhood that interests them in order to participate in what is relevant to them.
Reward: obtain points for sharing initiatives to, in this way, promote the image that being participatory generates individual and common benefit.
Later, we discarded the idea of offering a reward to users, since we consider that people will feel motivated to participate if they see that their proposals are heard.
Value Proposition and Business Model
After working through the ideation phase and gathering a ton of information, we decided it was time to write our value proposition. To do this, we use several canvases in which we developed Paula’s joys, frustrations and works. In this way, we decided that our app would serve to help citizens of the same neighborhood who want to be actively involved to reduce their discomfort and create a feeling of community, at the same time that their neighborhoods improve.
Just as important as a well-founded value proposition is having a business model that supports the entire idea. Therefore, with the help of a Business Model Canvas, we define the way in which our app would get financed and all the expenses derived from its maintenance.
Being a non-profit app, we discard the idea that there are subscriptions or that people have to pay to use it. However, we have found a very important business opportunity in the information that our app collects. In this way, our main source of income would be both municipal and local political institutions for which this information can be a very useful help.
With the help of the AGILE and SCRUM methodologies, we break up our value proposition into smaller, more manageable pieces, better known as user stories. It is the expression of a functional increase. Each UUSS carried out corresponds to the delivery of a piece of the value proposition that makes the final product enrich and complement each other.
Then, we refine them through an example mapping to obtain a better performance from each of them:
Next, we prioritize the functionalities that our MVP should have, based on the UUSS that we considered most important. For this we use a sequencer in which we order the characteristics from highest to lowest importance.
And, after this prioritisation exercise, we developed our MVP, which is nothing more than an excuse to validate our hypotheses or UUSS. Typically its goal is to satisfy a user’s needs. We developed only the features that we included in the first three points of the prioritisation:
This is how ParticipApp! arises, our solution, which consists of giving voice to the daily issues of the neighborhood.
Wire and task flows
Information architecture is the structure and organization of a product. In addition to helping users find what they are looking for, it also talks about who we are, gives an overview of the product and a strategic foundation. After analyzing the needs of our product, asking ourselves questions to understand our users, and inventorying our content, we reached into the wire flow of our solution.
About the task flow, we designed two based on the main two tasks our users will do while using our product.