Redesigning an approval process


OrgSync was an online SaaS 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.

I led the redesign of a complex process used by schools to review and approve student organization events. I was involved from initial problem and goal exploration, through creating views in code for development, to promoting the new feature at launch.

The problem

The event request system was an approval process that allowed students to create campus events and submit them for approval. Administrator involvement was required to approve events, reserve rooms, secure supplies or catering, ensure safety, and more. The tool needed to keep all parties up to date on the status of the request and its requirements.

Users were running into roadblocks trying to use this popular but dated tool, and feature requests and support tickets were growing steadily.

Project goals

Improve communication
between student life administrators,  event reviewers, club advisors, and student leaders.

Record history
to maintain actions on the event request, and act as record to reference in future.

Defining the users

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 personas, I focused on the roles of these users who our team knew personally, and with whom we had established relationships. I 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 assigned 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.

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 success. We categorized the needs based on user role.

Slides showing notes listing user needs and wants.

Notes were captured in Keynote files and shared with the team and customers. At this budget-conscious startup, we leveraged Keynote however we could, even to build clickable prototypes.

User flows and scenarios

I developed customer journeys for many use cases. I included actions—or lack thereof—that could throw roadblocks into the event approval process.

I converted these user flows to clickable wireframe prototypes in Keynote, depicting what different user roles 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.