A screenshot of the new Zipwhip Software
I led the redesign of several of Zipwhip 2.0’s core messaging features, making the platform faster, easier, and more intuitive for users. The improvements boosted customer satisfaction by 25% and lowered churn, while creating a scalable foundation for ongoing feature innovation. Two years later, the product’s success contributed to Zipwhip’s $850 million acquisition by Twilio.
Before:
Zipwhip’s 1.0 software was at the end of its lifecycle. Common actions were scattered across the interface, often hidden from users at inopportune times. Technical debt made it nearly impossible to update the existing application, and the product needed a full refresh to remain competitive.
A screenshot of the original Zipwhip Software
After:
We launched Zipwhip 2.0, a refreshed and more robust product that provided a foundation for future innovation. The update led to a 25% increase in CSat score and significantly lower churn compared to 1.0. Customers immediately reported saving time and finding the software easier to use. 
Approximately 2 years after launch Zipwhip was acquired by Twilio for $850 million.
My Roles:
UX Design Lead
UX Researcher
Context:
Zipwhip was a mid-sized startup focused on business-to-customer texting. The flagship product allowed customers to “activate” existing landlines and text their users through a verified number. I joined the project during early 2.0 design work, after approval and initial discovery had identified key opportunities.
I was trusted as the design lead to drive the redesign of high-impact features, including the To: Box, Contact Details Panel, Templates, and Automated Messaging for the MVP. Those can be seen in the sizzle reel below.
Each of those features could have a case study of their own, but it's one thing to release a shiny 2.0, and another to live up to the promise of iterating on features you've already built. Because of that, I proposed, organized, and ran a usability study prior to launch. It was important to confirm and modify design work on elements we knew we would launch with. It was even more critical to prioritize what would come next. Direct user feedback is a fantastic way to prioritize that "next" work.​​​​​​
Iterating Beyond the MVP: Templates & Dynamic Fields
As mentioned, one of the major new elements of Zipwhip 2.0 was the ability to have templated messages. We knew from previous research that this would be valuable. During the usability study we confirmed that many of our customers had various other documents with common messages they'd send out. These customers would have to copy and paste messages into the Zipwhip application one at a time. This was time consuming and inefficient and caused friction. Additionally they would have to manually enter in names of contacts.
We also knew that we could make these messages more personal. This was the birth of Dynamic Fields. Mail merges have existed in word processing products for a long time, so that was going to be our starting place. Text messaging apps at the time did not really utilize this technology. A little personalization was found to go a long way in the study.
We would ultimately combine the template feature with the contact details panel feature. Since I had designed those I was able to quickly springboard into this feature. 
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, importantly dynamic fields were clearly called out in the composition window. They could either be selected or typed in.
Templates UI in context.
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.
An error message for templates.
We wanted to balance protecting the user from error with ease of updating, so changes to the fields could be made nearby.
A larger view of a partial error message for templates.
When sent, the message would appear as any other text message.
A template with dynamics fields, shown after it has been sent.
Once the feature was released we heard from customers about how much time they were saving by using the feature. In some cases it was hours a week. Proof that even something relatively simple can delight a user and save customers a lot of work!
Back to Top