Home > User Experience > UX/UI Case Study: ParticipApp!. A tool that gives you voice for the… | by Litzanna | Dec, 2020

UX/UI Case Study: ParticipApp!. A tool that gives you voice for the… | by Litzanna | Dec, 2020

UX/UI Case Study: ParticipApp!. A tool that gives you voice for the… | by Litzanna | Dec, 2020

We begin our design challenge once we identify our archetype persona and its problems and needs.

Once here, we use the HMW technique () 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 , 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 , fostering a sense of and obtaining ?

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 , we presented the ideas that each of us had had. We ended up , making the decision to group the four ideas into one. The result was the following:

It is an app that, using , 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 and existing and even create them. The most voted or followed initiatives will be communicated to the 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 .

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.

After working through the ideation phase and gathering a ton of information, we decided it was time to write our . To do this, we use several canvases in which we developed , . In this way, we decided that our app would serve to .

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 , we define the way in which our app would get financed and all the expenses derived from its maintenance.

Being a , we discard the idea that there are subscriptions or that people have to pay to use it. However, we have found a v in the information that our app collects. In this way, our main source of income would be both for which this information can be a very useful help.

With the help of the , we break up our value proposition into smaller, more manageable pieces, better known as . 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 should have, based on the UUSS that we considered most important. For this we use a 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 arises, our solution, which consists of .

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.

Task flow of creating a new complaint
Task flow of supporting an existing complaint

Source link