User-Centered Design

Every project should start with identifying a problem to solve, whether it's a new feature or an entirely new product. For this one, we identified that college students wanted an easy way to communicate with instructors, coaches, and advisors.

This project was slightly unique in that we'd already collected user feedback for another effort, which was a (much larger scope) app for making student life easier. Out of that project's user interviews came some pretty convincing feedback: students want to know where they stand, academically, and only want to talk to faculty when necessary.

In talking with faculty about our findings, we also learned that academic advisors, in particular, wanted to better communicate with students and ascertain information from them in a more efficient manner. This gave us multiple problems to solve.

We were also able to learn more about both students and faculty, which led us to revise our personas documentation. Personas help us identify with and think like users throughout the product life cycle.

Starting with our original problem to solve, we broke down the high-level requirements discovered during our interviews into user stories (yellow post-its).

We also grouped the user stories into categories (blue post-its), which gives us an idea of how the product's structure might look.

To prioritize development, we listed desired outcomes (purple post-its), and realigned the accompany user stories. This meant identifying which persona was the most important (student), and which of their goals were most important (communicating with faculty). Following this format, we were able to create an initial product backlog.