Redesigning an approval process


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 creating views in code for development, to promoting the new feature at launch. Because our small team of designers and developers was cross-functional, development was also involved in the design phases. Likewise, design was involved in development, and I worked in the Rails codebase to refine the UI before feature launch.

The problem

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.

Project goals

Improve communication
between student life administrators,  event reviewers, club advisors, and student leaders.
Record history
to maintain and convey actions and comments on the event request, and act as record to reference in future.

Defining the 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 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.

Umbrella Administrators

These users manage a walled section of the software and have ultimate decision-making permissions.

Administrative Reviewers

These users have been designated within the event request system to review and approve or deny the event.

Custom Reviewer Element Reviewers

These users become reviewers if the event request contains specific responses that trigger this reviewer.

Student Leaders (Event Creators)

These users initiate the event request in their student group by completing required online forms.

Researching needs and wants

We knew, from months if not years of customer feedback, the general desires of our users—that feedback prompted the start of the project. I 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.

Image showing notes listing user needs and wants.

Notes were captured in Keynote files and shared both internally and externally as the project progressed.
At this budget-conscious startup, we leveraged Keynote however we could—even to build clickable prototypes.

User flows and scenarios

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:

Image of annotated wireframe showing student leader view.

Julia (Umbrella Administrator) logs in after automatically receiving a notification that an event request was submitted.

Image of annotated wireframe showing umbrella administrator view.

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.

Image of annotated wireframe showing student leader posting comment to conversation.

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.

Image of annotated wireframe showing umbrella administration sending message to a reviewer.

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.

Image of annotated wireframe showing a reviewer setting approval status.

Iteration and development

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.

Final interface

Image of final conversation page.Image of final event details page.Image of final event request form page.Image of final event request approval page with status modal.


View more work

Building a user research program

Measuring usability with SUS scoring