overview

research process

AGILE

Forming our Group

This project took place in a mock agile class, where we split into two groups of roughly ten people. We were each tasked with coming up with an idea to help the public during the COVID-19 quarantine, where we would work within the Agile framework. After deciding who within the team took on what role (Scrum Master, Product Owner, etc.), we started brainstorming ideas for our app.  We quickly settled on something food related, as that affected most of our households. This eventually formed into the app idea of putting in your current ingredients and coming up with recipes based off those ingredients.  We presented it to our professor, which took on the role of stakeholder in the mock agile workplace, and she accepted it.
‍

Familiarizing ourselves with Agile

Each sprint would last a week and we has already lost some weeks due to Covid and the switch to online, so we quickly got started on creating a backlog of what we wanted the app to have. Then we did planning poker to assign what tasks would take longest. We quickly realized what stories needed to be worked on first to lay the groundwork for the rest of the app.

It should be noted that our class was almost entirely UX, with my team being completely UX majors with minimal programming experience. We made sure our stakeholder knew our final product would be incredibly high-fidelity wireframes in Adobe XD, not a coded app. But if this were a real-life scenario actual development would then be the next step in the process.
‍

Research

Ground Work

To start off the project we wanted to make sure everyone on the team knew the functions we wanted in the app, who it was for, and how it would look. To complete this the Scrum Master and Product Owner delegated the first tasks to the team including:

• Style Guide
• User Personas
• Journey Mapping‍

Since I had previous experience in working with Journey Maps (read about it here), I was on helped lead that task. By creating the journey the user would take while using the app we hoped to make sure we covered our bases with the already created stories. This journey map also helped us to curate what we wanted the users to have as the main tasks, if these tasks made sense to the users, and get an overall sense of who the users of the app might be. Though our journey map was entirely text due to the time constraint, it still was a great exercise and incredibly helpful in gathering the scenarios users will be in.

Journey Map PDF

After finishing with sprint 1 and getting feedback from the stakeholder, we started to get our minds on what the screens would look like.

design

Low fidelity

First round

Our first set of wireframes came relatively quickly due to our short sprints.  We simply made the lo-fi wireframes of the main screens based off the tasks we planned out from sprint 1. We made a rudimentary flow between these screens to show our stakeholder how the user would navigate through the app and see if it felt natural.

Lo-Fi Versions of the main tasks

Lo-Fi Versions of the main tasks plus some alternate design and settings

Second Round

For the next sprint the team split into 2 groups. One group was the designers, working on the next set of low fidelity wireframes. While the other group started to work on gathering the data to put inside the high-fidelity wireframes. I chose to be a designer.

It was this sprint where our project scope started to creep substantially. As you can see below, our lo-fi screen count over doubled the previous sprint. We also not only included new screens to fill out the previous sprint, but new functionality such as favoriting recipes, difficulty meter, hands free mode, and other accessibility features. In the end, we had roughly 18 main pages that would need to be fleshed out for high fidelity.

Detailed versions of the Lo-Fi (each frame has the intials of the person who worked on it)

Detailed versions of the Lo-Fi (each frame has the intials of the person who worked on it)

While these features were always in the backlog from the beginning, seeing them on the screens caused our team to second-guess some of the functionality due to time restraints. This was backed up by our stakeholder, wondering if we would be able to finish the project with the polish we had promised her at the beginning. From here we cut down certain features, so as our finished product would be as polished as we had promised and all the main features that users would need to use the app would be there for MVP.
‍

Final pages after pulling back the scope of the app

High fidelity

First round

We quickly got started on creating the high-fidelity wireframes next sprint. With all members on the design side now, we turned out the hi-fi wireframes with very little prototyping functionality.  This was to show the stakeholder what the direction we were going to take the design and how we cut out features to provide a more comprehensive experience.

This was also the sprint in which we found we should’ve been creating an iteration document, so as to document what changes we have been making to the wireframes and the reasons why. With a big design team we were losing track of why some things changed from lo-fi to hi-fi and how we came to those conclusions to tell the stakeholder. This was something I would contribute too once a day just to keep track of the design work I did.

I personally designed most of styling for the cards seen here, not much on layout or any functionality. I wanted to mimic a sort of Google Material aesthetic and keep things consistent throughout the app.

Hi-Fi versions without prototyping

Second Round

After getting feedback from the stakeholder on how the design styles looked and how while we may have we cut back on the features, it led to a much more feasible product. This overall energized the whole team and I personally went into the last sprint excited to see the final product.

Finally, we came to the last sprint. The outcome for this sprint was the final finished prototype with full interactions.  My task within this sprint was to do the prototyping. I did end up doing a bit more than that, simply due to how Adobe XD works. I ended up having to create copies screens with slight adjustments, just to get the user flows correct.

Hands free mode

All the recipes included in prototype

Search and Filters

Main tabs, Settings, and Login

View Interactive Prototype In Adobe XD

Validation

Presentation

At the end of the semester, as a team we presented out product to both the stakeholder and the other team in the class. While a good portion of the presentation was focused on how we worked within the agile framework, we also got to present on what work we contributed to the project and of course the full prototype.

From this presentation we were given feedback as a team as if it was the end of the project from the UX side and we were handing it over to a development team.

Feedback

Due to the limited time, and learning how to work within an Agile framework, we got lots of great feedback on improvements to the design.

With every sprint being a week, we were in constant communication with the stakeholder, and with the communication we were able to get a clearer picture to what they wanted. It also greatly helped to have the other team look at our project as it was developing, to get the outsider perspective and catch things we couldn't see due to being too close to the project.

take aways

Agile Methodology

This was my first introduction to Agile. It was a great exercise, and it was incredible how much it helped to acclimate me to the actual workplace.  Though I do wish there was a software side to this project, as since it was solely UX on our team it was slightly misrepresentative to how UX fits into agile (read Nielson’s & Norman’s thoughts on it)

User Research

The cornerstone of the entire project was the very first sprint where we laid out what we needed to do, who it was for, and why we were doing this project.  Without that research to base our designs off of, we would’ve been incredibly misguided and constantly second guessing on what we should be building. It always important to have a set of clear requirements or acceptance criteria up front.

Scope Creep

From the beginning of the project we had big ideas for the short time frame, something that happens to a lot of projects. Thankfully we had a great professor and a great team to catch this creep before we got too far along the project.

Importance of the team

You might’ve noticed I’ve used “we” a lot within this project story. This is because I don’t see this project as something I accomplished alone (in fact none of my projects could be completed alone). But this project something that the entire team finished together. I fit weren’t for the team I had for this project, I don’t think I would’ve gotten past the first sprint. If you want to ask them more about this project, or even check them out for yourself, click the links below.

• Alex Nelson
• Britta Grayvold
• Jake Paulson
• Kayla Reid
• Kyle Radomski
• Maddie Howell
• Weston Verhoff