But once I started attending meetings with the Agile team, I heard speculation about features that the end users might like. I was alarmed, so I reached out and arranged user testing with the end users. I also arranged for my Agile team to attend an event themselves, so we could see the end users schedule appointments with their current process.
The contact we had with the end users completely changed the conversations in my Agile team. We developed a tool that supports the end users' work and significantly reduces their workload. At the same time we no longer have data issues. The live events team couldn't thank us enough. And it didn't take longer.
Before I was brought on board, the plan was to develop the tool without involvement of end users. There were only a handful of them and they were all available through the corporate directory, so there was no obvious barrier to research. I was told that the Agile team already knew what the end users needed, because other stakeholders had explained the requirements and priorities.
The company provides retirement advice to employees of large organizations. The company holds informational events for employees at workplaces. After these events, company staff (end users) schedule free appointments with financial advisors for the attendees (=prospects). The appointments are held at the company's branches.
Until we developed this tool, the events team used pen and paper. Particularly at large events, this led to many double bookings, and issues with data purity and completeness.
I can't remember the last time I included a reset button on a form, but it actually makes sense in this tool. It allows the user to quickly remove all of a prospect's Personally Identifying Information (PII), so others can't see it.
These are screenshots from the Axure prototype that I created for user testing.
The blurred fields are used to identify the employee/prospect.
This is the term used within the company for the employer.
This value is also persisted within the session.
We created the scheduler primarily for in-person events at workplaces but it can also be used for e.g. webinars.
The channel value is persisted within the session, so that the events team member doesn't have to re-enter it every time.
See an earlier version that emphasizes advisor selection.
Map: Supporting our staff
The event team member who is scheduling appointments is usually not from the area.
Including an interactive map that shows both the prospect's address (orange pin) and the advisor branches (green circles), avoids awkward conversations about geography. The events team were thrilled with the map.
Error states: Try again or Continue as Guest
For event team members it was reassuring to have a way of addressing error states visible on the page. It gave them confidence in the tool.
Here's the prospect, whose appointment you're booking, and their address.
Third party scheduling app
The scheduling app is framed inside the page. It has its own button set and progress bar. All I could change in the 3rd party app were the primary brand color and the text on the button.
Recognition is better than recall
Including the advisor and address that were chosen on the previous screen, gives prospects and staff confidence in the tool.
The final version of the confirmation screen has less functionality than the first iteration.
See the earlier version and find out why I changed it.
When the appointment is scheduled, the event team member clicks Next Customer. They're returned to the starting screen. There channel and sponsor remain populated, but the prospect information fields are blank.
MADE IN PIXEL TOGETHER
Go to Linked In
Return to Home Page
So I created a way for end users to browse advisors. There were never more than 5-7 advisors available to choose from, so there was no point in creating a search function.
Fortunately I organized user testing with the end user team and they told us that 99% of prospects only care about the branch location. Specifically they care about how convenient it is to get to the branch from their home or workplace. That's how I ended up designing a giant map with just a little drop down on the side for advisor selection.
It's a great feeling when you can give end users what they really need.
At the outset of the project, stakeholders told us that most prospects wanted to select an advisor based on the advisor's specialization. Prospects would visit whatever location their preferred advisor worked in.
Through talking to end users, we found out that speed was the most important consideration for them. The longer it took to set up an appointment, the more prospects get tired of waiting and walk away. That's literally revenue walking out the door, so the need for speed was real. I removed the Print and Email buttons because of that.
The objectives for the Confirmation screen were: