Plan Builder

A One Man Ux Team and a Desktop Application
Story Context
  • I currently work at Jonas as a Ux designer
  • Jonas Fitness makes software for Gyms / Clubs
  • This software runs the entire club facility, from Check-In's to Contract Sales
1. The Problem
Compete Desktop

For this particular project... I was tasked with the design and iteration for our Compete "on the go" sales agreement module. This was the first project I was finally able to run through the entire Ux process. The evangelism I had been preaching since my hire finally came to fruition and I was given the green light to do it the right way.

This time... We needed to bring the users a way to sell agreements on a tablet so that they could potentially be just about anywhere and make a sale. Whether it be at a health convention or mall, they could sign someone up and take payment for it all through our mobile site.

This particular module... In our desktop software is very in-depth and cumbersome. It requires a lot of mental load on the user to understand how agreements work. This is due to the nature of the complex agreements that different clubs use. It could be an open-ended agreement or a pay monthly. You can add services like tanning or basketball. You can even add family members.

I began my research... By visiting clubs that use the desktop application. I started digging into the complexity to see if there was a way we could make it easier to use, lighten mental load and the training required to use it.

2. The Research
Balsamiq Mock up

Our research... We went to clubs and observed how they use the current desktop application to sell agreements. We watched as several newer salesman struggled to use the system and ask other more experienced users for help. We talked with users of the system only to find out it is one of the most hated modules in compete because of its complexity. Armed with some good observations we began to implement our strategy.

I compiled a team of 6... Consisting of developers, BA's and SME's and held a (Google startup style) design session. We shared our research and then I asked them to sketch out on a piece of paper how they would solve the problem, and gave them only 8 minutes to do so. After the 8 minutes was up, we hung everyone's ideas on the wall. Each person got 2 minutes to describe their idea. At the end, team member used small stickers to place on the ideas they liked best.

We decided, as a team... That using a stepped process to build a plan would be the best route. It would reduce mental load on the users, as each step is focused on a particular task, which helps prevent the user from getting distracted by the other clutter that is needed to create a new agreement. After each step, the plan builder section will fill in the details and start to take shape. We began flow charting out the process and using this as the backbone to begin design.

3. The Design
Compete Browser Based

Crafting the experience... Compete On the Go was an adolescent site at this point, already in the market for about a year. The design elements were already well matured as far as colors and patterns. It was just a matter of using the flow chart to begin designing each user step and decision point.

As I am also a one man Ux'r... I was tasked with prototyping and coding. I started with the design in hi-fidelity, but when I came to areas that I really felt needed user testing I created a paper prototype or Balsamiq to do some quick testing first. This was particularly helpful on some of the secondary pages where there were quite a few task heavy flows for the users.

The application would work like this... You come to the main plan building page and each step would be its own separate page focused on just that step. You would select step 1, which allowed you to select your base agreement to start building out. In step 2 you would select and enter in the members who would be signing and paying for the plan. In step 3 you would select various plan details and add ons.. and so on and so forth.

I built the static HTML site out with enough information to be used against a user testing script. We then went to the club and began to test it

4. Iteration
Front Desk Persona
working iteration

User Testing Gone Right... During user testing we were able to identify several design flaws. Part of the challenge of being a Ux'r and the main designer is that you can often fall into the rut of making user assumptions. Testing will quickly show you how wrong you were. We had tabs on the right where users can click down to individual names to add services. As the designer, my thought process was "lets overlay a box to call this out, with large text. everyone will see it and read it". Not so much as this small excerpt from user testing showed me. Most testers completely glossed over this black box.

This of course prompted some changes to which we retested with success.

5. Lessons Learned

The process works... The biggest lesson learned for this project was how important research is to help formulate a good strategy. Also an important lesson was how involving other team members in the design really helped us come up with unique solutions to the problem. This project was a huge success and well received. So much so that many of our clubs want to use this instead of the desktop application.

It really helped show the company how well the Ux process can work and how it creates a much better user experience. Because of the success of this project I have the green light to run all future projects through the process as well. The evangelism is finally starting to pay off.