EventPlanner

During our workshops, we used this tool to structure our thinking about the client's business related to developing the application. We clarified unclear areas by asking questions, and those to which the client had an answer, we noted on the board. This allowed us to understand the client's business goal, so that we could work together towards a common objective in the rest of the project.

Given that the client had an idea for an application, but not a fully defined vision and an understanding of the needs and goals they want to achieve for their users, we used this tool to describe what the application would be and how it would be perceived, and to answer questions about user groups and their needs.

With the participation of a representation of the imagined user group and business partners, we developed detailed personas who will use this application. From a business standpoint, we answered the question of how this application will be used, by whom, and what problems they face. This allowed us to avoid the risk of creating functionalities that are not tailored to specific users' needs.

Having all the information about the client's business, product vision, and target audience, we proceeded to create a user map. This allowed us to have a better understanding of user goals and behaviors in the context of the product. We created a diagram that presented general functionalities that users should have and much more precise ones, defining what users can do within the main functionality. This enabled us to determine which modules the application should consist of, while also verifying it with a stakeholder group representing potential customers.

We already know from User Story Mapping what functionalities the application can have. However, this was a pool of all the functionalities that could be implemented. Therefore, we took on the prioritization of which functionalities should be implemented first to deliver the minimum but most important value and which ones can be added in subsequent stages of application development. Our application development process also allows us to modularly expand the application.

At the end of the workshops, having a precise set of requirements for the client's application, we re-estimated the estimated costs of its implementation. Understanding how the application should work and what functionalities it should include allowed us to create a much more precise cost estimate. For better insight, we divided it into the cost associated with producing the MVP and the final version. The client saw the cost discrepancy and could ultimately make a decision on which direction to take.

For each event resulting from the User Story Mapping, our UX designer developed a path that the user can follow to achieve its completion.

Then, with all the paths in place, the information architecture was prepared. This allowed for a precise presentation of which views should appear to the user on this path. It is a crucial element of application design because it eliminates the risk of forgetting any views at the prototype design stage.

Our specialists prepared a low-fidelity prototype. This is the moment that clients enjoy the most because based on a thorough analysis, they can see how their application might look like.

To ensure that the prototype meets the expectations of the target audience, is intuitive, and users understand it, we organized workshops with a larger number of representatives from the client's user group to explore how they interact with the application prototype. The scenarios of the tasks prepared for execution on the prototype were specific, and the questions we asked did not suggest any answers. This allowed us to collect feedback that helped us improve the prototype.

Finally, we added colors to our prototype. The UI designer designed a color palette consistent with the user profiles, interactions, and animations. We achieved a fully interactive prototype that aligned with the client's business goal.

Based on the information gathered earlier, we prepared technical documentation for both the mobile application and the server-side application.

Having the technical documentation, we created a roadmap and a list of tasks that we will be working on to fully develop the product for our client. We also defined deadlines for each stage and a final deadline so that the client knows what to expect in terms of time frame.

We've started implementing the project and deploying the first functionalities. To make the project more transparent, we've used the Agile methodology, which allowed our project manager to smoothly manage the implementation of individual tasks within the team.

Keeping in mind the client's important concern about the durability of the infrastructure under sudden user growth, as well as the complexity of the application within the application development process, we've employed testing scenarios, automated tests, and load tests to eliminate the risk of releasing an application with errors into production.

After all functionalities were implemented by our programmers and tested, it was time for our client to review the application and deploy it to the Google Play and AppStore.