SimpleTexting UX Research and UI Design
I was consulted about a UX informed UI redesign of some dashboard features on SimpleTexting's website. What follows are articulations of three UX/UI problems, followed by solutions informed by usability tests.
Problem 1
A first time user who doesn’t go through the onboarding flow and decides to send a campaign arrives at a screen with no list to send his campaign to. And so we try to be helpful by letting the user create a list.
...but it seems we don’t help the user all that much. Now he has a list with 0 contacts and still can’t proceed to execute a campaign.
Research for Problem 1
In some sense the user can execute a campaign - if they select a list with 0 contacts, they are allowed to the next stage which brings them to this screen:
There may be cases where the user wants to send a campaign to 0 contacts - perhaps they are just testing the system before actually deploying a message to real contacts.

I conducted usability testing to gain some more insight into the nature of the problem. I let participants use my trial account to set up campaigns and to try and send them so I could get their input. The existing format was not overwhelmingly confusing. All users were able to eventually figure out how to send a campaign to multiple contacts. However, about half of them experienced varying levels of confusion around how to actually add contacts as addressees to a campaign.

In addition to this, another issue was brought up pertaining to the “new campaign” screen - a few users thought that a list containing 0 users looked like a toggle switch, which added more confusion to the process. I addressed these issues as follows:
Solution to Problem 1
Redesign the label for 0-contact lists to look less like a toggle.

Implement a warn message for campaigns being sent to lists with 0 contacts.

An empty list is displayed in the following image. Design interventions include a straight bar between the list name and number of contacts to eliminate any confusion that it may be a toggle switch (especially misleading-looking when the list has 0 contacts). The list label also has a yellow background to indicate that it has no contacts in it.
How do we help them along so that they’ve accomplished their task?
The next screen is brought up when the user presses “Next”. A warn dialog appears above the preview box after a brief delay. This dialog contains a link to go back to the compose page - indicated with slightly darker text and an underline - as well as information that the user may proceed with sending the message.
Why underlined links instead of large thumb-friendly buttons? Most folks using an enterprise-level texting solution will be accessing it through a browser on the desktop.
Here's how Solution 1 looks in action:
Problem 2
Our pricing method is based on ‘Credits’. For example by choosing $75/mo plan you receive 2000 credits which can be spent on messages. SMS message costs 1 credit, MMS message cost 3 credits. For some reason, this credit system seems to confuse people and we receive many phone calls to clarify. The pricing can be seen on our marketing page and is also accessible from the application, either when the user upgrades from trial to paid or when a user upgrades or downgrades their account based on need.
What about the way that pricing is communicated confuses people? What would you do to improve the way we communicate pricing? Would you completely reorganize it on the marketing website and/or the product pages? How?
Research for Problem 2
While working on this problem I gained access to the team Slack. Employee Shelley (all names changed for anonymity) weighed in with the following:

“I'd say one of the biggest points of confusion that I've gotten is people thinking that they can send a message to an unlimited number of people for a single credit, so I explain that it is 1 credit for each outgoing SMS. I tent to provide an example, such as "An SMS to 10 people would be 10 credits". In app, people tend to get confused when a message uses 2 credits each, which is what happens with an extended SMS (more than 160 characters). There is a message that happens once they go over the character limit letting them know this, so I tend to ask if they see that message, indicating that they've gone over. At times, they think the characters left count at the time is from the original 160 characters, but it's from the remaining characters for the extended SMS (it first counts down from 160 to 0 for a standard SMS and then goes to 143 and counts down again for the additional characters allowed in an extended SMS). Explaining that helps to clear up that confusion. Asking for their full message and giving them the total character count helps, too.”

Jacob added this:

“Hi @Josh Piggy-backing off of what Shelley said: a very common issue we encounter is that people believe that the billing is for messages, rather than credits. They are thinking that 500 credits is 500 messages, without understanding that we have 3 types of messages. This causes them to send out 500 MMS and not pay attention to the fact that an MMS is 3 credits and they go over their plan by 1000 additional credits. if there is a way to convey the 3 types of messages in a clearer way on pricing, that would be great! I think that could help reduce the number of calls we get to explain credits, the number of chats, and the occasional upset customer who was charged overages when the unknowingly sent MMS for 3x the credits they intended to use for a message.”

A full approach to solving this problem would involve a more thorough back-and-forth with customer support staff. For the scope of this solution though I limited my research to what was presented in the problem, as well as the auxiliary information sent by Shelley and Jacob.

Solution 2
Reorganize the hierarchy of elements on the marketing website.

Economize existing columns and add existing information on the product page.
Sketches:
Mock-ups
Problem 3
We just recently implemented some semblance of an onboarding flow using Appcues. So when you login for the very first time, you see something like this:
...but if you click the X and decide to ignore our onboarding flow, you arrive at an empty dashboard as follows:
What information (if any — who knows, maybe this is perfect!) or options should we present on the dashboard for a first time user or a user who has not generated any analytics or inbox messages? Why should we do this?
Solution 3
Judging by the information in the prompt - I believe that a light touch is best here. A small warning dialogue appears at the top of the dashboard for users that have not sent a campaign yet. If for some reason an experienced user who has previously sent messages using SimpleTexting does not have any composed messages, the warn dialog should not appear - it is an edge case that a user who has used the platform successfully would suddenly need a tutorial. There will likely be fewer people in that user group, than those who will be annoyed to see a warning dialog every time they don’t have messages queued. Again, it should only appear for users that have never sent a message on the platform.
Conclusion
The work done here was informed by my own experience deriving UX insights in the VR development process while running my own startup, as well as techniques presented by Steve Krug's seminal work Don't Make Me Think! Krug outlines ways to conduct usability testing on a tight (or no) budget. For this consultancy I wasn't provided with any data or analytics from the website. Instead I relied primarily on conducting usability studies with friends that were unfamiliar with the platform, as well as the "trunk test" where I would print off a page, hold it at arms length, and see if I could identify the hierarchical elements of the page without reading the text.

The design of all of the mockups was done in Adobe XD without any access to the SimpleTexting codebase. Further iterations before deployment would involve much more rigorous standards of UI design. It is generally good to keep things rough in the UX research phase to be able to rapidly adapt to new information before final design and deployment.

For further research, I would like to create two versions of each of these solutions, and perform an A/B test, specifically tracking which version of the page caused users to consult
SimpleTexting UX Research and UI Design
4
91
0
Published:

SimpleTexting UX Research and UI Design

4
91
0
Published:

Tools

Creative Fields