In contrast to working on projects with my peers who are familiar with product development, working with sponsors whose expertise is not in tech was an eye-opening experience. It was challenging at times to interpret our sponsors’ feedback and to build our solution, but by the end of the project, I learned to...

Tackling a problem like misinformation was a bit daunting at first. How could I address the needs for so many people from diverse backgrounds who experience different challenges in our problem space? Feedback from project pitches and debriefs with our capstone advisor challenged me to prioritize inclusive design. I researched and regularly thought about the diversity (in age, ability, socioeconomic status, ethnic background, etc.) of our users and how those differences affect the usability of iSIFT. This helped me make more informed design decisions and prioritize features that accommodate for as many user needs as possible. After testing and pitching our project, I noticed that reducing the level of ability required to use iSIFT made our solution more accessible, useful, and effective for more people, beyond our target population.

Sometimes our sponsors' requests did not align with our users' goals and needs (based on our user research). It was challenging at times to interpret our sponsors’ feedback, but by the end of the project, I learned how to better communicate with clients about our project's development, leverage their expertise to inform certain design decisions, and lead constructive design critiques. Most importantly, I learned how and when to defend my design decisions to advocate for our users.

As our project concluded, my team and I prepared a handoff document for another capstone team interested in continuing our work. This document featured all the tasks we would have prioritized if we had more time. These tasks include: