Kickoff Meeting and Research
After the initial kickoff meeting, I knew we had to hit the ground running. I could sense that everyone had passion about the idea, but I wasn't so sure if everyone had the same passion while actually CREATING the project. To try and take advantage of this initial spark of passion, I had the team start on the process immediately.
I divided the literature review and competitive audit evenly among everyone as it was a rudimentary step within the process. This strategy was intentional, as it would start pointing me towards the peers I could trust with completing work and those who I had to be more cautious with. I wanted to help everyone see the vision I had for the project, and my goal was to ignite the fire within my peers who didn't have that passion quite yet.
User interviews and persona
As we began to move into more complex and fluid stages of the project, I noticed my first signs of trouble. I tasked everyone with finding 1 suitable candidate for us to interview. Not only this, but I wanted everyone to proctor the interview for their recruited interviewee, as I wanted everyone to learn something from the process. This part of the process was particularly challenging for us, as scheduling interviews that worked with all of our schedules proved to be difficult.
I had also realized that the intial excitement had worn away from my teammates, and that the rest of the project could be increasingly more difficult as the energy dies down. I did my best to push everyone to get their work done, and a majority of my teammates would still communicate well and do what I asked. Everyone managed to get their notes in from the interviews but I knew I still had to shift my management strategies soon.
I had realized by this point that when my team was assigned solo work, we would procrastinate and wait until the last minute to do it. This would not only give us lower quality work, but also almost push us back in timing for the original schedule I had set. My next goal was to try and make as much of the future assignments groupwork, this way we could all sit down and get it done together.
This was a success, as we blazed through the requirements phase faster than I originally expected. We sat down in person and had one online meeting to talk about what our persona would need from our service, and it seemed like everyone was excited again to work on the project, as the design portion of the project was right around the corner now.
Wireframing and prototyping
With the initial wireframing, I chose to split the work into asynchronous work again, as everyone seemed to be very enthusiastic about finally designing our prototype. I gave us a weekend to fledge out some basic flows and then we'd refine it in our next in person meeting. It was unfortunately around this time that I had realized some issues arising within the team that I had to try and solve.
The team all had varying levels of understanding of Figma technical skills. A majority of my team had only taken one prototyping class and I was the only one who had worked with some of the more advanced features on Figma. This would severly slow down our prototyping phase if I didn't address the issue and plan around it accordingly. So, I started with a quick rundown of some Figma basics to get everyone up to date, I explained and demonstrated some of the more advanced concepts in Figma that we would be using often, and I decided to assign specific sections of the prototype based on everyones understanding of the program.
Our team had some peaks and troughs during the prototyping phase, but in the end we got it done on time. During our user testing, the team was vigilant, potentially since we were nearing the end of the project. With no more bumps in our path, we managed to reflect some of our user insights into our prototype, and these reflections can be seen in our finalized prototype. The project was done, and we all came out learning something new, just as I had originally hoped.
With the initial wireframing, I chose to split the work into asynchronous work again, as everyone seemed to be very enthusiastic about finally designing our prototype. I gave us a weekend to fledge out some basic flows and then we'd refine it in our next in person meeting. It was unfortunately around this time that I had realized some issues arising within the team that I had to try and solve.
The team all had varying levels of understanding of Figma technical skills. A majority of my team had only taken one prototyping class and I was the only one who had worked with some of the more advanced features on Figma. This would severly slow down our prototyping phase if I didn't address the issue and plan around it accordingly. So, I started with a quick rundown of some Figma basics to get everyone up to date, I explained and demonstrated some of the more advanced concepts in Figma that we would be using often, and I decided to assign specific sections of the prototype based on everyones understanding of the program.
Our team had some peaks and troughs during the prototyping phase, but in the end we got it done on time. During our user testing, the team was vigilant, potentially since we were nearing the end of the project. With no more bumps in our path, we managed to reflect some of our user insights into our prototype, and these reflections can be seen in our finalized prototype. The project was done, and we all came out learning something new, just as I had originally hoped.
With the initial wireframing, I chose to split the work into asynchronous work again, as everyone seemed to be very enthusiastic about finally designing our prototype. I gave us a weekend to fledge out some basic flows and then we'd refine it in our next in person meeting. It was unfortunately around this time that I had realized some issues arising within the team that I had to try and solve.
The team all had varying levels of understanding of Figma technical skills. A majority of my team had only taken one prototyping class and I was the only one who had worked with some of the more advanced features on Figma. This would severly slow down our prototyping phase if I didn't address the issue and plan around it accordingly. So, I started with a quick rundown of some Figma basics to get everyone up to date, I explained and demonstrated some of the more advanced concepts in Figma that we would be using often, and I decided to assign specific sections of the prototype based on everyones understanding of the program.
Our team had some peaks and troughs during the prototyping phase, but in the end we got it done on time. During our user testing, the team was vigilant, potentially since we were nearing the end of the project. With no more bumps in our path, we managed to reflect some of our user insights into our prototype, and these reflections can be seen in our finalized prototype. The project was done, and we all came out learning something new, just as I had originally hoped.
