OrgSync was an online software product used by over 400 colleges and universities to manage student engagement. OrgSync enabled these institutions to communicate with students, track student involvement, and manage campus programs. Student organizations also used the tool to manage events, files, membership rosters, photo albums, and more.
While at OrgSync, I led the redesign of a complex process used by schools to review and approve events run by student organizations. While an event approval process existed in the software, it was not meeting customer needs. I was involved in this project from initial exploration of the problem and goals, through handoff of prototypes to development. Because our small team of designers and developers was cross-functional, development was also involved in the design phases. Likewise, design was involved in developments, and I worked in the Rails codebase to refine the UI before feature launch.
The event request system was an approval process that allowed students to create campus events. Administrator involvement was required to approve the events, and often to secure supplies or space, ensure safety, or manage other details. The tool needed to keep all interested parties up to date on the status of the request and its requirements.
Users were running into roadblocks trying to use this very popular but dated tool. Feature requests and support tickets were growing steadily.
Development time was slated to rework the tool from the ground up, to make the tool easy to use and learn, while meeting the needs of a variety of users.
This tool would be used by vastly different users with different interests and goals. We had interesting customer relationships at OrgSync; we knew customers by name, spoke with them often, and spent a three days with them each year at our annual conference.
Rather than creating impersonal personas, we focused on the roles of these users who we knew personally and with whom we had established relationships. We kept the actual, real-life users in the forefront of the design process to ensure that we met their needs.
For example, while working on solving problems for administrators, we focused on how to create a tool that would work for Becky at her university who needed to add 12 additional custom reviewers, but not letting that feature get in the way of Steven at his university, who needed no custom reviewers.
We did assign names to users in each role while building wireframes, since user names and profile photos appear throughout the application and this feature.
These users manage a walled section of the software and have ultimate decision-making permissions.
These users have been designated within the event request system to review and approve or deny the event.
These users become reviewers if the event request contains specific responses that trigger this reviewer.
These users initiate the event request in their student group by completing required online forms.
We knew, from months if not years of customer feedback, the general desires of our users—that feedback prompted the start of the project. We began a comprehensive compilation of customer needs and wants through the following methods:
The result was a comprehensive list of over 50 wants and needs that the new tool needed to achieve for a successful redesign. We categorized the needs based on user role.
I developed use cases for a variety of users and scenarios. I took care to include actions—or lack thereof—that could throw roadblocks into the event approval process. I converted the user flows to clickable wireframe prototypes in Keynote, depicting what different users would see when one user attempted a task that affected other users. This helped us spot flaws in our thinking or scenarios that we may have overlooked.
One scenario example, and its annotated wireframes:
George Student creates an event. What happens?
Julia Admin receives notification for George's request.
Brad Advisor receives notification for George's request.
Julia logs in, sees that Brad has to approve before she can make final decision.
One week later, George is still waiting for his approval. He logs in to ask why.
Julia receives notification that George asked why his event was in limbo.
Julia logs in, sees that Brad is the blocker, and asks Brad why he hasn't reviewed yet.
Brad receives notification, and logs in to review and approve or deny event.
George (Student Leader) created his event, then reviews the request that was automatically submitted:
Julia (Umbrella Administrator) logs in after automatically receiving a notification that an event request was submitted.
George logs in a week later to check the status of his event requests, since he hasn't received notification of approval yet. He leaves a new comment asking what is causing the delay.
Everyone in the conversation receives notification of George's comment. Julia logs in to find what's causing the delay, and discovers that Brad (Administrative Reviewer) has not responded to the request. She sends Brad a message.
Brad had ignored the previous notifications he received about this event request, but now he logs in, reviews the previous message thread and event details, and submits his approval.
I frequently reviewed progress on prototypes internally with the development, customer success, and leadership teams. We also reviewed at regular intervals with the customers who would be using the feature. Customer review was critical (remember the 50+ user wants?) to ensure that we were on the right track with the design.
At all stages, design and development also worked together. The complex system contained several automatic actions that would trigger when a user performed specific actions, and developer input was critical to working through what could be done and what should be done from an engineering perspective. Concepts and layouts went through several iterations to test the feasibility and usability of the pages.
When development was complete, the new event request process was released to a small group of beta testers before it was launched to all customers.