Case Study

Overview

EduShop is a POS website that saves bookkeepers time by promoting online payments and generating realtime reports. The EduShop team adds payment pages based on a bookkeeper’s build specifications.

Problem

Gathering specs is time consuming and frustrating.

Users & AUdience

The EduShop team and clients.

Role & Responsibility

Design lead and primary researcher. I had to choose a form builder that allowed custom coding, conditional questions, multiple confirmation recipients, and integration.

Solution

Design a form to reduce email exchanges, standardize the order of build specs, and increase client satisfaction.

Scope

• Terms will be defined and related to common variations.

• Client will be able to skip irrelevant questions.

• Errors will explain what needs to be done to proceed.

• Submissions will be emailed to the CRM.

• Submission copies will be emailed to the client as confirmation.

Constraints

• Neither EduShop or the CRM have a form feature for clients to communicate with the EduShop team.

• CRM tickets are generated by emails.

Process

To visualize and plan, I drew a wireframe concept of the task flow. I sectioned by who, what, customer, reports, and submission. Each category would be a screen to break the flow into manageable pieces. After submission, the form would contact the CRM and client with confirmation.

I defined terms in the form. The form provided an opportunity to teach clients what common terms mean. Many clients confused terms which slowed the build process. This created a negative experience for the client and EduShop employees. I researched synonyms by going through ticket history and interviewing EduShop support members. If several clients frequently used synonymous terms, the synonyms were mentioned in the official definition for easy association. Terms specific to EduShop were given one definition.

I tested the spec order against the build flow. To improve build efficiency, the specs needed to follow the order that fields in EduShop appeared. I did this to eliminate EduShop team’s screen clicks. Previous solutions mimicked the order of reports and inventory exports. That output was unaffected by the spec order for EduShop.

Next, I crafted a prototype using the third party form builder. Some questions have different options show if a qualifier is selected. Conditional questions kept the form shorter if a build was simpler. EduShop Production, Support, and Operations gave feedback that I recorded. The next version addressed needs and suggestions.

After iterations of prototype, team review, revise, we launched the form. I wrote intro statements for the EduShop team to use when asking clients to use the new form.

Outcomes

Most clients adopted the form without feedback or comment.

Clients who were opposed to the form were asked to share what wasn’t working for them. Those staunchly against the form were interviewed by Support and Operations. All feedback was shared with me. I partnered with Operations to determine the best strategy to onboard all clients. We landed on creating custom versions of the form for key clients to satisfy unique requirements. For those without specific needs and who were only opposed to change, Support and Operations used screen-share meetings to demonstrate the form value.

Over the next 3 months, the form went through several iterations as pain points were identified with further client use.

A year after launch, 90% of clients were using the form.

• Support ticket quantity drastically reduced.

• Ticket time to solve was cut in half.

• Satisfaction ratings improved.

• Less time was spent on gathering specs, allowing more time to add new fees for the same or different clients.

Curious about the form? Try the demo

Lesson

I hesitated a while before proposing the form to my manager and team. This prolonged the EduShop team’s frustration, felt exponentially during peak seasons. I learned that if I have an idea that could improve the experience for the team and client, to propose it sooner than later. The form immediately eased pain points for the internal team and external user.

Iterations could have been reduced if I stood by my writing. The form started off wordy with small text and fields. The original design also got longer as a user progressed, rather than having natural break points. If the user reviewed their answers before submitting, the visual burden could be exhausting. Want to see? Compare the original

If the form builder had more flexibility, I could add more helpful microcopy and UI text. The available options aren’t as obvious or intuitive as I’d hope. Some interactions could use improvement. I’d like the solution to be more elegant but constraints outweighed the value.