Workshop

The workshop for solution development was based on the Sprint 2.0 methodology. We gathered for a week and defined a facilitator role that wasn't fixed so that everyone had the chance to take on that role. We also optimized the steps and conducted more than one activity per day, making the process more agile and allowing for possible "reflections."

The 8 steps of the sprint are:

Presentation & Understanding the Challenge

We had a brief recap of our context and user research, which was also the primary validated data for the project. After the presentation, we used How Might We to generate initial solution ideas.

Recalling that we needed to focus on the problems of:

• Lack of practical application and direct contact with the teacher;

• No feedback on learning or little interaction among peers;

• Long-duration courses or those with little flexibility.

These problems cause demotivation and devaluation of the taught content and are the main consequences that the product will have to address. To confront this scenario, we did a HMW and formulated three statements:

• How might we make the content more practical so that students get more excited about the course?

• How might we make the platform experience more interactive and increase student satisfaction?

• How might we increase networking during the process to make them happy?

After the HMW, we aligned on the key problems we would address and how we would focus creativity in building the solution.

Definition & Prioritization of Problems

We optimized the dynamics with the "brainstorm → impact vs. knowledge matrix → prioritization" script. This made the process agile and faster without losing efficiency. Additionally, the method was essential for generating internal debate about the problems and making the process more enriching.

Definition & Prioritization of Solutions

Prototyping

We gathered references and went through the "Crazy 8s" dynamic for the initial sketches. Here, we also discussed visual references, primarily based on games and educational platforms but not limited to them.

After the dynamic, we decided that the MVP (Minimum Viable Product) would focus on calendar features, content application, and course tracking. Additionally, the idea of linking learning with beehives emerged to reinforce the concept of knowledge construction and community within the platform.

Check out the initial app screens here:

User Test Preparation

We decided that the test should serve two purposes: confirm whether the app was intuitive with the basics and understand if users would grasp the functionality of the study plan in the calendar.

To optimize and reach more people, we used Maze to conduct and track the test metrics.

User Testing

The tests were crucial for understanding the project's trajectory. The main realization was that the metrics were not entirely satisfactory, especially for the study plan test.

Additionally, we identified that the flow was not as clear, and the calendar, our feature that we considered a differentiator, was not ready and needed several changes.

See full report below:

Sprint Conclusion

The last stage of the sprint involved a review of key points and the definition of next steps. Thus, we concluded that the definition and prioritization were the most beneficial aspects of the cycle, as it marked the beginning of the solution and provided a debate in which everyone contributed with experiences both within and outside the user experience. Other crucial moments were the prototyping and user testing, as we identified the gaps in the MVP, especially those related to the features we considered the product's differentiators.

Ultimately, the sprint was essential for product development. It helped us set deadlines for each stage, streamlined the process, and advanced in the construction of the solution.