Jump Messaging App Process
Overview
UX Designers by nature are always going to advocate for the customer. It is engrained in each of us to make the lives of our user easier by uncovering the problem they are encountering and then providing a solution.
Working for a start-up occasionally has its struggles in balancing the customer need and the business need, because typically, in order for the business to succeed or stay afloat, design and development need to move quickly. More quickly sometimes than proper research will allow.
So what do you do in those situations? Build blindly without doing the research to meet the business deadline? Push back for more time from the business? (Sometimes that works, but again, startups NEED to move quick.)
I can’t say that I found the ‘perfect’ solution for this, but I found success in gathering high-level data and research and turning that around quickly into a feature design on one particular project.
Background
Jump Software is a platform to help improve local business owners online presence.
The software has 3 key sections that allow local business owners the ability to connect and engage with their customers online; Listings, Reviews, and Social.
Recently upon completing a competitive analysis, Jump realized that they were missing out on an opportunity for users to connect with their customers; thus a request was made to the product development team to build a messaging feature.
The Problem to be Solved
Initially, the team was frustrated that we were asked to build a feature without any sort of research backing it up. The only evidence we had to say that building this feature was the right way to go is because a handful of our competitors already had it, and their customer churn was significantly lower than ours.
My PM and I sat down to discuss how we could get buy-in from the other departments and stakeholders on this request when we had zero background initially on whether our users even wanted or needed a messaging app. We understood that regardless of where or how the request may have been produced, it was our job to build it in a way that met the business needs while giving the user a feature that was actually something they were missing and needed for their own business to find success. In order to understand how we could create a meaningful feature, we came up with some business and customer outcomes. We used these also as hypotheses to base our research questions around, that way we could validate if these were actual outcomes that the user wanted.
Research
The first step to getting buy-in was to find data in the actions our users were already doing.
To gather a lot of responses in a short amount of time, I created and conducted an in-app survey using AppCues and asked questions, such as:
Which social platforms do you have for your business?
What is the primary way you communicate with your customers?
Is the phone number listed on your GMB, website, and social media a landline or mobile number?
How often do you currently text your customers?
Rate your interest in a new tool that would allow you to receive and send text messages to your customers?
Key Takeaways:
There is major interest in a texting solution. (not as much interest *yet* for other messaging integrations)
84% of our businesses have already text their customers at some point
Appointment Management and SMS marketing are the key drivers of interest.
75% of SMBs don’t have a CRM
“If you had the ability to message customers I never would have left”
“How would I use messaging…? Too many ways to list.”
Competitive Analysis
In order to understand the market need a little better, my PM and I analyzed companies that we felt were successful with creating a messaging feature. Based on the common feature offering of these companies, we found a few things that validated what our customers had told us in their survey responses; such as the need for messaging app to either be mobile responsive or a native mobile app, the minimum messaging need is for a message to be sent via SMS, and lastly that message templates are necessary to streamline the messaging process.
Game-Plan
Typically I would prefer to spend more time researching, but as mentioned before, my team and I needed to move quickly. We were working with a short time-frame.
Based on the information we gathered and our need for speed, my PM and I came up with a game-plan to present to the business for final buy-in before we began our design and build phase.
We determined that we would build the absolute, most basic MVP and beta test it with a small group of users in production. The reason for this decision was the cut out all the fluff that we thought would be “nice to have” and focus on the core functionality that we needed, then gather more information from our users as they used it to determine which features to add to it later.
We came to this conclusion because of the astounding response from users and competitors that the base messaging platform need was just the ability to send and receive text messages. Beyond that basic need, the other feature offerings were additional things that would enhance the experience, but we weren’t finding a ton of common patterns in the market for what those features should be, as every company had vastly different add-ons.
Ultimately, we determined that we would make this first beta rollout functional, reliable, and usable. We would allow the customers to tell us upon using it how we could make it pleasurable.
From there we wrote out all the things that this MVP needed and broke that down into small deliverable milestones for the developers and me to focus on. We kept it as simple as numbering them to the left to determine which milestone each piece of functionality would fall under.
Design
For this part of my process, I again studied the market and looked for common interaction patterns in desktop messaging platforms. Platforms that I drew most of my inspiration from were iMessage, Telegram, Slack, Google Hangouts, and Line.
I drew up a few different user flows in LucidChart and presented them to my team for discussion.
From there, I came up with our MVP Interface(s) that I A/B tested with the beta group. There were as follows:
New message as a button in the top right corner.
New message button as an icon in the top left, inside the messaging table.
I wanted to test the different ways to display the create a new message button because in our platform whenever a user needs to complete an action, they can easily identify what the action is on a page because the action is displayed as an orange button in the top right. I found that for messaging, however, that the create a message button was most commonly displayed as an icon within the same table.
Upon testing these designs I discovered that the right image was more successful because it matched our users mental model of messaging.
I continued doing small and quick A/B tests internally when I stumbled upon design pieces that could be handled in different ways.
Final MVP Design and Prototype
In all, this process had a fairly quick turn-around. It took my PM and me about a week for discovery, and myself about a week for design and testing.
From here, the dev team will begin building this feature and push it to production to our beta group. We will conduct user research on this feature while in prod in order to understand the future needs of this feature before making it public to the rest of our users.
Conclusion
My favorite part about building this feature was how quickly we were able to get buy-in once we decided on a game-plan. It was fun to see the skeptics turn to believers when we presented our solution.
I feel like this project was so successful because my PM and I kept our dev team, customer success team, and stakeholders in the loop at every phase. That allowed us to pivot fairly quickly if we started to go down the wrong path. It also helped me understand the development possibilities and limitations so I could design properly from a developers perspective.
One thing I would do in the future is try to get more research in on some of the “nice to have” features for messaging to determine one that stands out, so we could include at least one thing to make this feature “pleasurable” upon the first release.
Overall, I really enjoyed how quickly and smoothly we were able to get this out, and how collaborative everyone was throughout the process.
I would definitely use this process again with a few minor tweaks in the future.