WEB APPLICATION
Event central 2.0
A one-stop-shop event management application that helps Event Leads successfully raise the $2 billion in funding required to keep St. Jude Children’s hospital running each year. Event Central 2.0 is a web-based, internal application designed to connect various applications, request forms and data together in one place and provide the tools and resources to help them confidently manage successful events.
THE PROBLEM
Event Leads need to set up their events in a handful of different applications in order to manage successful events. They also need to request support, services and materials from a dozen or more teams within ALSAC. Processes are often changing and keeping track of what to do and how to accomplish it can be challenging, so the leads miss critical steps in the event management process and spend valuable time tracking down applications and filling out repetitive forms to get the resources they need.
PROJECT ROLE
On the project team of eight people, my role is to be the user advocate while also understanding and incorporating the vision of the business. I designed the flow, the functionality, and the UI of the application, tested with users and iterated on the design. I assisted in determining the project timeline and how to break it into pieces. My role also included writing the tickets and working directly with developers and QA to ensure the application matched the design.
RESPONSIBILITIES
- User research and user testing
- Flow and functionality
- Wireframes and hi-fidelity mockups
- Low and hi-fidelity prototyping
- Assist in determining and adhering to a project timeline
- Writing Jira tickets and refining with developers
- Work with QA and developers to ensure the final product matches the design
THE GOAL
Develop a web app that walks Event Leads through the event management process, opens up visibility into the request process, and provide links to all applications and data related to a single event.
DURATION
May 2022 – Present
Full-time contractor position
EMPATHY
INITIAL RESEARCH
I came into this project at the tail end of the research phase when the previous UX designer took another position. I started out reviewing the dozen or so interviews she had conducted with the various SMEs and business partners as well as the extensive current event management process flow she had created. From there I set out to confirm her findings by conducting a few of my own interviews to answer some of my questions and ensure that I had a solid understanding of the project goals from the business perspective as well as the actual pain points and frustrations of the users.
From the beginning it was clear that we had a wide range of users who needed the application to accomplish a diverse set of tasks. The business stakeholders and the actual users were also not aligned with what this application needed to accomplish. The users were extremely frustrated around the current event management process and ready for a solution that would allow them to focus on generating revenue for St. Jude Children’s hospital and less on figuring out the new processes, filling out forms and tracking down the right application to use.
During the initial research we learned that throughout the lifecycle of an event, more than 40 systems or applications were being utilized.
Below is partial snapshot of the Event Lifecycle flow that was designed by the previous UX designer but gives an idea of the complicated mess of Event Management.
PAIN POINTS
1
TOO MANY PLACES
There are too many applications and resources in so many places that it is challenging to find what they need. It is also difficult to remember how to use all of the applications and systems and Event Leads lose time that should be spent on fundraising.
2
Event Data is wrong
Event data is added to multiple applications and is not updated everywhere, so many of the systems have inaccurate information. Users come up with a way to track data on their own, leaving others without access to accurate information.
3
Who is doing what?
During the life-cycle of an event, there aren’t clear roles and responsibilities of who is working on what. Requests are sent to various teams with no visibility into whether it was received and where they are in the process. Tasks get missed and users don’t know where to go for help.
4
PROCESSES CHANGE
Processes and applications change frequently and aren’t communicated to the users. They often discover changes while trying to use an application or when they are reprimaded for not submitting a form.
PERSONAS
Here are three of the personas used for this project. During research and design, seven personas were used to capture the various users, each of whom would use the application for a different set of tasks.
Delila
“I pride myself on being the information source for my team, but processes continually change without letting us know and I’m left without the answers my team needs.”
Delila is an admin user who supports the staff in multiple offices in her area on everything they need
AGE
44
YEARS AT ALSAC
12
PRONOUNS
She/Her
ROLE
Admin
EDUCATION
BA in HR Management
HOME OFFICE
Miami, FL
GOALS
- Quickly create events using only the most basic information necessary
- Allow event leads and staff to find the event codes etc. on their own
- Be able to get accurate event data
- Pull lists of events based on specific criteria
- See everything happening with an event at a glance
FRUSTRATIONS
- She is expected to be able to help the leads with their events but often doesn’t feel like she knows when processes change, so ends up providing incorrect information
- She creates 30-40 events at a time and the form is currently time-consuming, complicated, and requires information that isn’t yet available.
GOALS
- Quickly create events using only the most basic information necessary
- Allow event leads and staff to find the event codes etc. on their own
- Be able to get accurate event data
- Pull lists of events based on specific criteria
- See everything happening with an event at a glance
FRUSTRATIONS
- She is expected to be able to help the leads with their events but often doesn’t feel like she knows when processes change, so ends up providing incorrect information
- She creates 30-40 events at a time and the form is currently time-consuming, complicated, and requires information that isn’t yet available.
GOALS
- Quickly create events using only the most basic information necessary
- Allow event leads and staff to find the event codes etc. on their own
- Be able to get accurate event data
- Pull lists of events based on specific criteria
- See everything happening with an event at a glance
FRUSTRATIONS
- She is expected to be able to help the leads with their events but often doesn’t feel like she knows when processes change, so ends up providing incorrect information
- She creates 30-40 events at a time and the form is currently time-consuming, complicated, and requires information that isn’t yet available.
Laura
“I spend way too much time at my computer trying to figure out who to contact for the next step of the event processes instead of managing relationships with donors”
Age: 30
Years at ALSAC: 5
Role: Event Lead
Pronouns: She/Her
Home Office: Los Angeles, CA
Sharice
“I am constantly frustrated by the lack of tools to manage the event details and share them with my event team including the vendors so they know where to be and what to do”
Age: 26
Years at ALSAC: 1
Role: Event Planner
Pronouns: She/Her
Home Office: Memphis, TN
Flow and Functionality
My first step in designing the application was to come up with the structure for the application. By reviewing the interview notes and analyzing the current event lifecycle chart, I created a list of tasks that users would need to accomplish using the new app. From there, I reimagined what the user flows should look like for each of these tasks.
User Flow for Creating an Event
I stripped away the current process and reimagined the flow for each task from scratch.
This image represents just one task a user might need to accomplish. The actual document includes 18 tasks, each with multiple outcomes.
A clear list of features and functionality emerged that would be necessary from the app.
User Flow Bubble Map
Using the user flows for each task, I pulled out all the actions that needed to be completed on the UI.
Then I grouped those actions together where possible to determine the pages.
Pages could then be grouped together to determine the menus. It was clear that there were essentially two groupings, the user dashboard and a dashboard for each event.
App Site Map
Using the bubble map from above, I mapped out the hierarchy of the application.
Each page clarified what tasks and functionality should be incorporated along with how the user should flow through the application to accomplish each task.
The map also includes key users and stakeholders to utilize for questions and user testing throughout the design process.
Once this map was completed, I walked through the vision with the development team, the project team, key business stakeholders and a representation of the users to ensure the vision was on track with expectations.
WIREFRAMES
Event Central 2.0 was designed with a large external monitor as the primary device based on research that this is the primary way our users would access the application. The application also supports laptop and a half-screen size to accommodate users traveling with access to only their laptop. These users indicated they often work with two applications open side-by-side on their screen. I also designed components with the possibility of expanding to mobile in the future, if it is determined that this would better support Event Leads in the field.
Taking this into consideration, the wireframes were designed for desktop, while the high fidelity designs include responsive sizing down to a half-screen size to accommodate laptop users.
User Dashboard
I designed the user dashboard first to help me get a feel for what data is most important to each group of users and to give them a sense of ownership and confidence in the events they are working with and managing.
The dashboard is completely customizable to account for the various user roles who are here to accomplish very different tasks.
Designed to give a snapshot of events that are coming up, critical notifications for events, a way to monitor the health of events, and a list of upcoming tasks.
Task list
Some of the most passionate feedback I received from users revolved around processes changing and users feeling it was unclear how to do their jobs. Even users who had been with the organization 10+ years were frustrated by being unable to find tools that had moved, or being reprimanded for failing to complete a form they had never heard of. To combat this, a task list will be included where program teams can update the steps that are required, and each step will have detailed instructions and links to necessary tools.
Tasks must be able to be checked off to give everyone a clear picture of where the event is in the lifecycle.
Instructions must be included on where to go and how to complete each task.
We need to allow for different views so users can get a quick understanding based on whether they need a high-level overview or a granular deep-dive.
Event Team
One of the critical pain points that came out of the initial research was that users were frustrated because they didn’t know who was working on what. By giving users the ability to create a team for their event, everyone can see at a glance who is working on each aspect of the event.
Users can add new team members and edit this list.
Team Members can be assigned an Event Role to give more explicit understanding of what they are responsible for on the specific event.
When users add a request to their event and the request is assigned to a someone, that name and role will auto-populate here.
TIMELINE
I worked closely with the Product team to determine how to break down the application into pieces in order to utilize a trickle release methodology which would give users critical functionality sooner. We prioritized each piece of functionality that the application would provide and divided them into releases. We also looked at the user pain points to determine what was most important for the user, and what pieces would excite them and get them on board with the new changes to their work flow.
RELEASE 1
The first release had no UI components and focused on pushing the data from Event Central 1.0 to other forms, increasing data integrity and reducing time spent typing the same information.
RELEASE 2
- Event Creation
- View and Edit Event Details
- Add a Feature to an Event
- Search for an Event
- Manage Event Umbrellas
- User Profile
RELEASE 3
- Add a Request to an Event
- Copy an Event
- Task Management
- Add Additional Features
- Bulk Upload Events via CSV
- View Source Codes
ReleaSE 4
- View Budget Details
- Event Calendar
- Task List and Manager
- Power User Tools
- Email-Based Requests
- Additional Event Details
Release 2 USER TESTING
Because my users were internal, I was able to easily conduct multiple interviews with each of my user types as well as the project team and the business stakeholders to ensure that the product was in line with what the users need and the vision by business. Being able to see and click through was a turning point in being able to understand what each side was looking for and determining what was critical, what was nice to have, and what was a poor assumption on my part when designing the wireframes.
TYPE
moderated
LOCATION
remote
Participants
24
Length
30-60 min
TOP 3 INSIGHTS
1
MORE THAN JUST A SEARCH
From the beginning of the user testing, it became obvious that users were interested in using the search functionality for more than just finding specific events. They wanted to be able to create lists of events based on specific criteria and export those lists to Excel.
2
CHANGE IS FRIGHTENING
The team took the opportunity of developing a new application to implement changes to event management including labeling the external applications as “Features” and changing from “Master Events” to “Event Umbrellas”. When encountering these terms in the application, users felt very unsure of themselves and even nervous that they would break something.
3
TERMINOLOGY IS KEY
There was an unexpected amount of confusion from the users when testing the filters and for some of the input fields when creating events. After doing some digging, it turns out that several of the terms used by the IT team were not used in the same way as the users. Gaining a comprehensive vocabulary was critical to eliminating that confusion.
RELEASE 2 SOLUTION
EVENT CREATION
Creating an Event in Event Central is a critical component in the project. Our field administrators are the primary users for this page, and each generally create 50-120 events at one time in the fall.
FORM FIELDS
Designing an elegant form is deceptively difficult as each field requires thinking through a dozen questions from error messaging, character restrictions, how tabbing should work, how to give the user the knowledge to answer confidently, etc. The functionality for each of these form fields was carefully considered and rigerously tested with users.
Event Details
A sidebar to the right of the form gives users a way to quickly review their information in a condensed way. They can also see at a glance any required fields that are still missing. Users loved this functionality.
After creating their event, the user is presented with options to view that event, or start over and create a new event which allows them to easily move through their flow of creating multiple events in a row.
helping users make informed decisions
During user testing, users were very unsure about the new term “Event Umbrella” although this was basically a rebrand of a term they were already familiar with. Users were choosing an Event Umbrella at random from the dropdown list, which would have caused havoc for the data integrity and defeated the purpose of using the Umbrellas, which is to group events together year-over-year.
I added a search modal which explains what an Event Umbrella is and how to use them. Filters assist the users in finding the correct umbrella for their event.
Giving users confidence
Because several of the form fields changed, and feedback from users indicated they were often unsure of what information to enter, I opted to use a toggle for the hint text. This allowed me to include longer descriptions and instructions for the users to feel confident they are entering the correct information.
By making this a toggle, the users who are comfortable with the form can hide that hint text to simplify the UI and see more of the fields at once, thereby allowing them to move through the form faster.
EVENT DETAILS
The Event Details page is the heart and soul of Event Central, giving everyone in the organization a view into each event with equal access to accurate information. Eventually, each element of an event will have a separate page with additional details. For the initial release, the idea was to create a dashboard that allows users to view and edit core data.
INTERACTIVE EDITING
While my initial thought was to take users back to the event create form to make edits and additions to an event, feedback from users indicated that the event leads making the edits were fearful to go back to the form in case they broke something. They were also hoping for something a little more fun to use.
In response, I designed an edit mode that allows the users to make edits directly on the Event Details screen so they can see how the changes will look and feel confident that they are editing the correct information.
Hand Holding
When it came to adding features and requests to the event during user testing, users were confused and fearful. To counteract these feelings, I created a more robust modal that explains each item and breaks down the process into smaller steps. The new version gave them the confidence they needed to utilize the functionality.
For requests, the development team was unable to have all of the requests available for the first release, so we added links to all the other requests needed for an event. The users were ecstatic about having them all in one place where they could easily find them.
Designed for Half Screen
Users felt confident they would primarily use extra-large, external external monitors when working in Event Central 2.0, but would occasionally need to work on their laptop screen when traveling for events; and they often view two applications side-by-side. Taking this into consideration, we designed the application first for External Monitors. From there we designed for full-width laptop size and half-screen size.
Designing for half-screen also puts the team into a good place to develop for mobile, should that become a requirement in the future.
EVENT SEARCH
The ability to search for and find an event is obviously a critical component to the application. What was most interesting during usability testing, however, was that users wanted more from this page. Due to a lack of accessible reporting functionality, the users were hoping to utilize this page to pull lists of events that meet specific criteria. To assist with this request, I added additional filtering options and added a button to export the list to Excel.
MEETING HALFWAY FOR CUSTOMIZATION
One of the repeated painpoints was around customization and making it faster and easier for users to find what they are looking for. Eventually, the user dashboard will provide this customization, but we wanted to accommodate this need more immediately, so we included an additional table that appears above the main search results that displays if the user owns any events. This list gives the Event Leads quick access to the events they need and filters just like the main list.
Filter down to the nitty gritty
In order to give the users the ability to pull lists that meet very specific search criteria, the filters are custom dropdowns that give users complete control. The Cost Center filter allows users to search from a high level grouping of territory, then specify at the area level, and even down the granular cost center level. Filters were grouped logically to minimize the number of options while still giving users everything they need. And the best part is that these are reusable components from the Event Create page.
Designed for Half Screen
The table format is highly desirable for listing events because it allows users to scan by column and view the maximum number of events at once, which was the main focus for these users. However, as we move to smaller screen widths, the table format becomes cumbersome as users have to scroll side to side.
For half-screen views, I redesigned the list to a card view which allows users to review all of the data for an event at once.
EXPORT TO EXCEL
As discussed above, an important aspect of event search turns out to be the ability to filter lists. Some users are often asked to provide lists and data on the number of events that meet specific criteria. Currently these analysts must either anticipate these requests and track keep this information in a spreadsheet, or they have to reach out to event leads and request the information which is time consuming and sometimes inaccurate.
By providing detailed filters along with an Export to Excel button, we are reducing the probability for error and giving these users the ability to get error-free data immediately.
LEARNINGS
While I encountered many interesting problems during the course of the research and design for this project that allowed me to expand my understanding of UX, I think the learnings that I am most thankful for are from working in a much different style. This was my first encounter working on an agile scrum team with front-end and back-end developers as well as several QA.
1
AGILE METHODOLOGIES
Jumping into an agile scrum team, I quickly learned the benefits and drawbacks of working on a small team, breaking large projects into manageable chunks, and pushing to meet shortened deadlines.
I have also been instrumental in assisting the Product Owner in writing all the UI Jira tickets, conducting UX reviews of tickets before they are pushed to production, and prioritizing tickets to ensure they are completed in a logical order to maximize usability.
2
DEVELOPER HANDOFF
Trying to convey the design and functionality in your head to another person is fundamentally challenging. Things that seem so obvious to you are often not so obvious to others. Throughout this project, I searched and tested a wide variety of methods for developer handoff to find the right balance of specificity and autonomy for this team. I landed on detailed Jira tickets with links to prototypes where necessary and close communication with developers to encourage them to come up with better and sleeker solutions.
3
MENTORING OTHER UXERS
Shortly after starting on the internal UXer team, there were four of us working on seperate projects with little to no communication. However, I wanted the applications to feel unified. So, I started weekly meetups with the other designers to align our designs. That meetup turned into an hour of design critique, encouragement and morale boosting. This has been an incredible learning experience and forced me to rethink how I design in collaboration with others.
NEXT UP FOR RELEASE 3
The Event Designer
The initial concept was a simple interface that steps the users through managing an event from beginning to end. The Event Designer is how we plan to achieve this.
The questionnaire allows us to ask logical questions that correspond to the features and requests. For example, rather than checking a box for “Legal”, we can ask “Will there be alcohol at the event?” Adding a feature or request will automatically add team members, update task lists and add budget information.
ADDITIONAL EVENT PAGES
The Features, Requests and Team will allow for additional real estate for each section, making it easier to provide valuable details about the health of the feature. For example: for peer-to-peer fundraising, it could show how many people have created pages and how much money has been raised. Requests will show status and comments to keep all communication and information together in a single location.
HELP SECTION
The Event Support team requested early on for a help button be added to each event which would generate a support ticket with specific event information added automatically because users generally fail to include this information. I’m taking this one step further by providing a place on the UI where these requests can be easily tracked by the user. It will also allow them to follow what is going on without having to go out to the Jira ticket because the users generally have a phobia of Jira.
BUDGET
Displaying accurate and up-to-date budget information will be a game changer for the users. Currently there is no single place they can go to retrieve comprehesive budget information regarding their event, including a simple total of revenue raised or expenses incurred. The users are currently tracking all of this information by extrapolating data from various spreadsheets and inputting into personal spreadsheets along with valuable notes and projections which are inaccessible to leadership and lost if the lead leaves the organization.
“Are there any plans on making Jamie the dedicated UX designer for all things experiential / territories? Or like supreme UX designer leader or something. I smile every time I look at EC 2.0”
– Business Stakeholder