In a site-wide upgrade, we began exploring the idea of an internal event management tool.

 

The user group we focused on was company administrators who are in charge of managing events with both internal and external focuses. We assumed proficiency with web applications and access to the information about the events. 

 

To begin, I mapped the flow of a user and the details they'd need to include. That flow is pictured below.

By talking with some office administrators, we learned that they wanted the tool to be quick, easy to follow, and flexible. They expressed some concern about the value of having an event manager separate from Outlook (used company-wide). A big challenge they discussed was the sheer volume of input options. Additionally, they mentioned a need for a "quick" version that would allow them to insert only the most basic information and either go back for the rest or leave it blank permanently. A use case that was cited was a very self-explanatory event (e.g. Lunch). 

 

From there, I used Balsamiq to wireframe out the different pieces of the flow for creating an event. We decided to use a wizard model so that users wouldn't have to think about multiple aspects of the event at a time. We were trying to avoid decision fatigue and remove the intimidation/burdensomeness of a wall of input fields without a personality or natural flow. 

 

In the same vein, part of the site redesign was introducing a more unified and helpful tone. To comply, I mostly used questions rather than descriptive headings for each piece of the wizard. This way, an administrator using the tool would feel like the computer was working on their behalf to gather the necessary information. 

 

I collected feedback on a high level from some administrators (within our own office due to time constraints). With their input - and general approval of the direction - I launched into a more granular round two of wireframes (ultimately culminating in a clickable pdf available here). 

As with many users, our administrators responded really well conceptually to the wizard, but struggled to get past the aesthetics of the wireframes. Once we had their buy-in for the proposed set up, we moved into high fidelity mock ups. 

 

After each iteraction, we presented our mock ups (via InVision) to 2-5 potential users to guage agreeability, feasibility, and completeness. 

Using these mocks (over a few more iterations), we tested internally to find what was and wasn't working. 

 

Some things that came out:

- The image uploader felt clunky compared to everything else

- Users were frustrated by not knowing how far along they were (but they liked the simplicity of each step)

- A few of the slides felt redundant, and we learned we didn't need both tags and categorization. 

- The wording was well received, except the headers which - though charming - did not allow for quick parsing. 

 

With that information, we moved into the below (and final) iteration.