Before:
Zipwhip's 1.0 software was at the end of its lifecycle and the company needed a complete refresh of the product. In addition to UX challenges, tech debt had made it so that updating the existing application was nearly impossible.
The Screenshot above shows the previous version of the software. Common actions were spread across the screen and often hidden from users at inopportune times. Areas outlined in red dashes were areas that we paid extra attention to in the update.
After:
We had a stronger foundation upon which to iterate and a refreshed flagship product in the marketplace. This resulted in a 25% increase in our CSat score and significantly less churn than the original 1.0.
My Roles:
UX Design Lead
UX Researcher
Zipwhip was a mid-sized startup focused on business-to-customer texting. The flagship product allowed customers to "activate" their existing landlines and text their customers. It allowed them to have a verified number that they could interact with their customers through.
I joined the company when design work on Zipwhip 2.0 was early, but not at the very beginning. The project had been approved and early discovery had been done, so known areas of opportunity existed.
I was tasked as the design lead to work on the To: Box, the Contact Details Panel, Templates, and Automated Messaging for the MVP. Before launch, I proposed, organized, and ran a usability study which helped us iron out some final details.
Our marketing launch video can be seen below.
Templates & Dynamic Fields
One of the major new elements of Zipwhip 2.0 was the ability to have templated messages. We knew from previous research with customers that this would be valuable. Some of our customers would have various other documents with common messages they'd send out. These customers would have to one at a time copy and paste messages into the Zipwhip application.
We wanted to make their lives easier and knew that we could. We also knew that we could make these messages more personal so would develop Dynamic Fields. A little personalization was found to go a long way and we wanted to make it easy for customers to do this.
The first step was bringing the messages into the Zipwhip application itself. Note that the dynamic field can either be selected from a menu so the customer didn't have to remember all of them, or typed in manually.
Once a template had been saved the user could easily access it while composing a message. Editing templates was kept only on the template details page to keep the mental overhead on possible actions low in this high traffic area of the UI.
We wanted to protect our customers from accidental errors, so when one of their recipients didn't have all the fields we'd give them a very prominent error message, and stop them from sending the message. Our hypothesis was that no customer would want to send a "broken" message. That one wasn't hard to prove.
We wanted to balance protecting the user from error with ease of updating, so changes to the fields could be made nearby.
When sent, the message would appear as any other text message.
Once released we would hear from customers about how much time they were saving by using the feature. Proof that even something relatively simple can delight a user and save them hours of work!
