Overview

This is my team's project for CS 307: Software Engineering I. The class's goal was to teach us about agile development by having students create groups and build a software application by the end of the semester. The class was split into 2 sections: planning and development. Planning lasted approximately 2 weeks, which is not very conducive to following a proper UX design process... especially as the only designer on a team of 4 developers. Nevertheless, I pulled my backpack straps tight and did the best that I could. Not to spoil the ending, because things did not go perfectly, but I learned so much and am proud of the project we completed.

Design Time

As I listed at the top, I was the sole designer for this project. My teammates understood the importance of design, which was fantastic, but ultimately the design depended on me. At this point, with our Product Backlog submitted, we split to plan our various aspects of the application. We had a week to write and submit our Design Document, so time was a bit crunched.

I started this by looking into various applications that serve similar certain aspects of Amora to study and learn about their design decisions. I looked through Discord to learn about how they implemented social server design. Things 3 is a terrific personal task tracker with a simplistic, yet powerful, design. And Spark is an email client that manages to condense the complexities of email into an intuitive, helpful interface.

The First Wireframe

With these inspirations in mind, I created the first wireframe. It consists of 3 omni-present views:

1. Team Selection View — Having a fixed projects sidebar allows a user to quickly view all of their projects and switch between them. This is very similar to Discord and Slack, two applications our target users regularly use, so it should be familiar for them.
2. Team View — This is the view for a team. This first design assumes a user will be on multiple teams with multiple projects. Separating the tasks by project is an attempt to increase overall organization for a user.
3. Project View — Within each team is a project, indicated by the partially-filled circle. Each of these projects has unique tasks, and only the members of that team who are a part of that project.
4. My Day View — We had large ambitions of connecting a user's calendar with the view so that they could easily drag tasks onto their calendar to plan their day, as well as viewing their team member's calendars to plan a meeting.

Third Time's The Charm

The final iteration came after significant scrutiny from friends in other projects. I updated the colors to be more calming, and changing the font and spacing guidelines helps the application feel genuine and less cluttered — many people we talked to mentioned the original design felt overwhelming. In addition to some UI changes, we also updated some features:

1. The "Team" view is now a "Project" view — the people we're building Amora typically have one project with each of their groups. Removing the concept of teams removed steps to checking tasks, which many users appreciated.
2. Announcements panel — Within the project view, team leads wanted the ability to post announcements and reminders for their teammates. We placed this at the top of the page so that they're always visible, and they're only removed when a team lead deletes them.
3. Flagging important tasks — People want to know which tasks are most important, so we added flagging. We also updated our sorting algorithm so that it displays the most relevant tasks first, based on priority and due date.
4. My Day planning — We updated the "my day" view to just be a list of tasks that you want to accomplish that day. This change was made entirely due to development constraints

Building the Application

Now that the initial design of Amora was complete, we began coding the web application. To be fair, my teammates did the majority of the logic; I used HTML/CSS to make the website match the aesthetics of the design.

I learned a lot from the experience. Even with a pixel-perfect UI mockup and prototype, it is exceptionally difficult to translate that to a working application. The team tried numerous methods to transfer the design — Zeplin and InVision, to name a few — but we eventually settled on the engineers building the functional webpages, followed by me going through and fixing the HTML/CSS to make it appear as the design intended.

Lessons Learned

I'll admit that there were many aspects of the application that I forgot to include in my design — settings, messaging, and notifications, to name a few. But overall, this was the first project that I truly worked with a development team to bring one of my designs to life. The prototype is live, if you'd like to see it: https://team4amora.firebaseapp.com/. Overall, there's a lot I'd love to change about the design. I really want to conduct some more user research to confirm some assumptions we made. And there are some last-minute features we had to throw in to meet a grading criteria that really need to be moved in the user flow. But overall, I'm proud of the work my team and I accomplished.