Setting
Currently, Sicoob Institute has a system to monitor and execute the projects developed together with the Institute. However, the system did not provide a broad view of the project execution and tasks and made managing these projects throughout the year difficult. The process for the creation of a new product that met the necessary requirements to assist tasks execution and their management was started driven by this pain..
Purposes
1. Create a task flow that assist the users to execute projects, knowing what has to be done next;
2 . Assist the project execution management in a team distributed by Brazil;
3. Improvement of task flows, to optimize executed projects.
Design Process
To assist us in creating solutions to those problems, we seek to follow a process for the product development or your experience. For this, we follow a process consisting of four steps:
In practice our design process worked as follows:
The survey
In the beginning, there were several uncertainties about what the best way forward. So, we choose to start with interviews with Stakeholders and end users, who are people who manage the project execution and use the product with the same purpose.
Thus, it was possible to understand how these people execute and manage their projects on a daily basis, knowing their frustrations and expectations when using the current version of the product.
We started with a simple list of questions. And, with each interview carried, we got different views based on the experiences of each user. We traveled to another state to understand better their reality, and the answers contributed to gathering the hypotheses that would guide the product.
Interview with end users
One of the main frustrations collected from the questions asked was that it was not possible to have a task flow of tasks to be carried out, users did not know what to do next and were carrying out activities randomly.
Interview with Stakeholders
In order to also know the frustrations of those who manage the project execution, we sought to be alongside those who perform this function, which helped us to have more empathy in a setting in which the team was not included.
Immersion interviews endure an average of 40 – 80 minutes each. We casually sat down with each interviewee and let people talk about their daily routine, project execution, management and monitoring. We also carry out experiments and co-creations with users. So it was possible for us to learn from other products that people used to manage their projects as well.
Rafaela, 27 years old:
At the beginning of the conversation, Rafaela showed dissatisfaction with the current system. Some problems related to lack of communication and real-time project management were reported. To circumvent the limitation, she needs to use other software, just so she can monitor what is happening in the execution of her projects.
Problem detected:: Not being able to manage projects in real time causes frustration for the user in the project management.
To manage the projects, she needs to access other software and control through messages received via cell phone or email.
Michael, 32 years old:
Like Rafaela, Michael also reported problems related to lack of communication and real-time project management. Furthermore, he exposed frustrations with executing tasks randomly and getting results of them only at the end of the year, when users access the system and submit all actions carried out during the project execution.
Problem detected:Not having access to documents and proof of activities while they are taking place. It only has project data at the end of the year.
To manage the projects, she needs to access other software and control through messages received via cell phone or email.
The more we asked, the more we discovered things, until we identified a pattern with questions raised and main problems reported. This allowed us to map the profile of our users and what each of these profiles would like to be solved with the new solution. The variety of people allowed us to learn and generate hypotheses.
Personas
By combining the data collected during the survey and the patterns identified, we started to map the personas to our product. We also use the representation of demographic pattern and behaviors.
Here are some of the values generated from the survey and its development:
- Team learned the value of talking to users to understand the mix of behaviors and experiences;
- Ideas generated within the team were biased from our experience background;
- We learned that there was a mix of people and experiences within the Institute, but that we would be able to meet the variants with the product;
- An evolution occurred in the generated ideas, which were biased and not based on the pains and needs of our users;
- Naming the types of users, we were able to have more empathy and identification of the people who would use the product.
Defining the Product
With the survey carried out and the people defined, we had a perspective on how we could start looking at the question. We then decided to express in a few words what would be the product based on identifying the problems.
What is/does SINS?
Sicoob Institute's management system is an evolution of the current system, made for people who work together with Sicoob Institute and who need a more accessible, easy-to-use system that brings all the managerial and executing view of the projects that take place over the course of a year.
Free of complexity, helping the scalability of the project execution that directly impacts business growth. Unlike other task managers, Sicoob Institute system brings together powerful tools that help to follow a task flow with: Process flow, help in prioritizing tasks, demonstration of one task at a time (“avoiding overload”) and less effort for adoption.
With this process we realize that, many times, it is easier to define the problem we want to solve than to bring solutions without initial foundations. After a few days of work, criticism, data and materials collected during the survey, the team became unified in the product view and we were ready to start pursuing hypotheses and solutions for the product.
Hypotheses
With some hypotheses raised from the survey and real problems reported, our prototype building process started by prioritizing of what would be the main part of the product, as we needed to meet the main need first.
From this, we were able to identify three features that would be very important and would meet the needs of the user who manage and the user who executes them.
These three features being:
- Task flow creation;
- Project creation;
- Project execution.
From them on we knew where to start, time to get our hands dirty!
Scribble time
The first thing we did when the initial features to be met where defined was hold a meeting session to generate inputs and get to a solution based on the needs, work done jointly by all team members, regardless of whether they are developers, designers, PO or Scrum Master.
The idea of this moment is that all members participate in the solution and let all the ideas come out to generate more ideas and questions, maximizing our possibilities for solving the problem previously established, always accompanied by a Stakeholder to take key decisions.
Wiframes
From the ideas generated by the team, we immerse ourselves in the solutions brought to the product, exploring the solutions both technically and negotially. Right now it was just us and a whiteboard, with no digital tools yet.
After the journey of creating wireframes and low-fidelity prototypes, we felt we had arrived at an information architecture, user journeys and flows that made sense and could communicate what we were proposing without too much complexity and a new experience.
Wiframes
But now there was only one thing left for us... TEST!
The A/B Test
At the end of the discussions and creation of prototypes, we arrived at two prototypes with different solutions and we took both to the users, to understand which would best solve the problem in question.
Test A
At the end of the discussions and creation of prototypes, we arrived at two prototypes with different solutions and we took both to the users, to understand which would best solve the problem in question.
Missions
For the two types of user profiles we had for product testing, we defined some missions to be carried out, tasks that they would normally have to perform in their daily lives in the future.
Resultados
By applying the test, we were able to understand that the flowchart presented that way would not make much sense to users. This is because they were not familiar with it and faced difficulties in creating and visualizing it when using it. Thus, the users' experience would be harmed, bringing more difficulties in their view.
.
We also had Test B to learn more from users and come up with a solution that made more sense to users.
Test B
In the second solution, we tried to bring a balance between who managed and who executed the projects, based on the users background. We try to simplify the product without losing its essence.
Missions
As in Test A, we determined missions tasks to be performed, we brought to the second solution the focus to understand if we had a solution that would make more sense than the Test A flowchart and confirm other points observed in the test.
Results:
With the second possibility, we realized that users needed a task manager without much complexity, where whoever managed it would create the base tasks for those who would execute the project. Thus, it would not be necessary to faithfully follow a flow, being able to have the possibility of adding tasks, which would allow the execution and management with ease and without bureaucracy or generating rework with the system. So we had the following flow for users:
With that, we would be able to solve the problems reported initially and we established the purpose of the product:
-
You get access to the data you need from the project, without bureaucracy and at any time
-
Você consegue acesso aos dados que precisa do projeto, sem burocracia e a qualquer momento;
-
100% transparent to what is happening with the project;
The product progressively demonstrates to the user the information he needs, but only and when he needs it;
Brings freedom, but the possibility of creating inputs for your project, helping to improve it;
Accessible for less experienced users;
Help in continuous improvement of work processes;
Final Result:
Management users:
Conclusion:
It was a journey of learning. But, by combining our tools, processes and people, we are confident that we can generate a cohesive and user-friendly product.
The product is still in the implementation phase, but we can already see improvements regarding the management and execution of tasks, in addition to the real-time tasks notion and control and access to data at any time.
We are also taking the product to mobile, which will bring even more freedom for users to access necessary information when they need it.
We also hope that, with the data generated, the product will help with the scalability of Sicoob Institute's projects. Making each project better and more accessible and reaching a greater number of people who will be helped by the Sicoob Institute.