Micro-business CRM and Scheduler

A small cleaning business in Idaho was experiencing growing pains and difficulties with responding to customers after hours. Partnering with engineers and another UX designer for a bootcamp project, we discovered the unique concerns of a small business owner and delivered a product that allowed for business growth and enhanced customer service.

• How might we streamline and digitize a pen and paper file system?

• How much we reduce customer response time?

• How might we allow for business growth?

My Role

• UX/UI Designer

The Team

• 2 UX/UI Designers

• 5 Developers

Duration

8 week school project

Understanding the cleaning micro-business

I developed questions for and led the stakeholder interview. Developing quick rapport with the business owner, understanding his current pain points, and ensuring we had a thorough understanding of his desired outcome was at the forefront of my mind.

Stakeholder Interview Insights

• Currently uses Google Calendar for scheduling

• All customer files and records are kept in a pen and paper fashion

• Difficulty responding to after-hours customer concerns because they cannot access records

• Does not need employee records management

• Desires a means of technicians uploading images in the field, as well as clocking in and out of jobs

How many users?

After talking to the stakeholder, we quickly realized that the web application had a user base of four users at the time of design and development. We had direct contact with the stakeholder and the administrator and planned on reaching out to the technicians as the project progressed. Because we had the real deal a phone call away, we did not develop personas or customer journey maps. We could reach out and ask their perspective, and did nearly every Friday during our stakeholder meeting.

How should the content be arranged?

It was vitally important to me that whatever we designed made sense to the user and integrated seamlessly into their pre-established work flow. I interviewed the administrator/receptionist to better understand her current process of job assignment, technician management, and response to customer complaints. After our first meeting with the stakeholder, my UX colleague and I determined the information architecture and user flows of the web app. We understood there were two different aspects to the web app: administrative and in-field.

Administrative

• Assign technicians to jobs

• Schedule jobs after receiving a phone call from a customer

• Manage after hours customer complaints

How do other business scheduling dashboards work and look?

In order to better understand our product’s niche, I assessed the competition. There were various business dashboards that could meet the user’s needs, but the biggest barriers were financial. The stakeholder repeatedly mentioned that he did not have extra funds as he was growing his business to spend on products. Furthermore, many of these products provided services that the stakeholder did not want or need at this time such as billing, maps, invoicing, and credit card processing.

Initial attempt at designing for stakeholder needs

We determined together with the developers that the main dashboard view would be a great place to start. We wanted to ensure that the user had everything readily accessible from a single click on the dashboard side navigation. We also tried to provide options to customize the dashboard views with real-time tracking of in-field technician work, ratings of technicians, and customer information.

The take home message from our first attempts

My favorite part of this while process was that as we got closer to the stakeholder’s ideal, he would fine tune his desires and give us even more clarity. The stakeholder provided us with fantastic feedback again and again. Initially, we fell into the trap of trying to over complicate and over design the whole product. We had to revisit our information architecture and simplify the tabbed navigation. I had to simplify and strip down our user flows to their bare essentials, remembering the real world workflows we were trying to integrate with.

More stakeholder feedback

• Rating technicians was not desired

• Job notes needed to be associated with each customer, and linked together

• Live feed was not practical or necessary

• Viewing the schedule of up to 15 teams individually was essential

• Quick and easy to see gaps in the schedule

• Scheduling is based on zip code

The look and feel of the product

UI decisions were made using Material Design as the design system. Iterations were key to making this product really shine. Design critique, “hallway” chats via Slack and Zoom, preference testing with users, developer collaboration and stakeholder feedback all played a role in fine tuning. When considering color palette, users were quick to point out a purple/red color was reminiscent of spilled wine and hard to get up stains - not a good look for a cleaning business web app.

Reality check: does this work?

Usability testing insights

• Users wanted to click on the calendar and not the New Appointment button

• Users sometimes did not even see the button

• Icon meaning was guessed when navigation was closed

• Separate screens for editing and adding broke user flow

• Confusion regarding icon meaning within individual customer view

• Once a user was within a tab, they were

  able to accomplish tasks

Initially, I had designed separate screens for many actions, like editing or adding a new technician. This broke the flow for users and lead to a disjointed and difficult to navigate experience. Following Material UI’s Guidelines, I incorporated more modals/dialogs so users could stay on the page they were currently working on. This lead to greater focus on tasks for the user. It also made more sense in the technician tab because of how little information needed to be updated and gathered.

What about mobile?

Mobile responsiveness was difficult with the amount of information in some tables. We had to make decisions regarding the most important information for the stakeholder based on our conversations with him. We understood that checking customer records was the main task he would undertake after-hours. We also knew that he wanted technicians to clock in and out of jobs and upload job images in the field. Initially, I attempted to make a more responsive looking mobile web app. This lead to vital content being pushed down below cards, harder to navigate accordion style cards, limited view images with small areas for notes, and overall a difficult user experience.

Design critique and iterations made the difference in taking the mobile web app from mediocre to meeting stakeholder needs. Removing non-vital information, turning cards into a table format, full-screen images, and using more intuitive gestures like swiping to archive and edit lead to a better user experience. Placing the navigation on the bottom mimicked the ever-present side navigation of the desktop, allowing users to quickly switch between tabs.

Pixel perfection delivered

Throughout this process, I worked directly with developers. They had a lot of great insight into what was and was not technically possible. In one instance, they caught a user experience problem - increased load time due to images. With that information, I was able to iterate the table view of customers to allow for fast loading times, which are critical to a well run business.

Sometimes what we were able to design was not able to be built in the time available. This was the case when it came to the calendar view. My colleague and I had many long discussions about the calendar and scheduling keeping stakeholder needs in mind. He created a scrollable, multi-view agenda calendar which the stakeholder approved. However, the developers were only able to create a single calendar view with a drop down to select the cleaning team view.

What impact did this have?

The stakeholder was pleased with all the designs delivered and the attention to detail. He repeatedly called our UI “the dream.” I anticipate that the stakeholder/business owner will be able to view customer details easily after hours and respond to concerns hours or days sooner. Technicians will have a seamless means of uploading images to a database, adding notes as they go, ensuring good customer service. Scheduling by zip code will allow the administrator to decrease drive time for technicians, as well.

Next steps

If we had more time, I would have loved to fully iterate and integrate the in-field technician functions. This was slightly beyond scope for the first feature release, but was a key desire for the stakeholder. I’m contemplating turning the technician cards into a table view, similar to the customer view. The stakeholder mentioned he liked the images of the technicians, but I wonder if the product would feel more integrated with all table views. The developers also contemplated a React Native App, but did not have the time to build it. It would be interesting to design more functionality based on a native application. Finally, there are many buttons in the app that may be better served with iconography - a trash can instead of a delete button. This may streamline the app even more, leading to less text information for the user to process.

What I learned

This 8 week project from inception to shipped product was full of ups and downs. I delivered a design that was iterated through 100s of screens based on design critique, stakeholder feedback, developer collaboration, and Material UI Guidelines.

• The importance of managing stakeholder needs and desires with technical and time constraints.

• Iteration is key to making a product that not only looks good, but works.

• Design isn’t a linear process, sometimes you have to start over because you didn't understand.

• Less is more - don’t try to do everything. Just do what you need to.

• Collaboration makes a world of difference.