Messaging is ubiquitous in our world today, but what goes into a good messaging experience? How do users expect Messaging to work? How can we learn from others to provide a fantastic messaging experience?

Project Objective

Enable users of VoiceEdge to send messages to people important to them.

When thinking of a modern business communication tool, one would probably think that it would include messaging. From my own personal experience working in both small and large companies, I know that the modern workplace includes a lot of messaging. Be it Slack, Skype, Teams, or what have you, people today are using messaging a lot.

Knowing this, my stakeholders within Comcast always planned to include a messaging aspect to VoiceEdge. Not only is the need validated by our own working experience, but also from the sales people in the field who are talking to customers. More and more they hear the desire for business owners to be able to send texts from a business number, to communicate to clients over text for various reasons.

So the case is made for including messaging. Now we have to go make it!

My role on this project was as the main UX Designer, and aided by my Design Lead, and my two UI Designer colleagues.

Project Goals

Before I even sat down to start on Messaging, I had to nail down the goals of this feature.

• Goals: Design and build a messaging feature for VoiceEdge on mobile and desktop.

• Timeline: Deliver designs and documentation by 1/1/2020

• Vision: Create an easy-to-use, intuitive, pleasant messaging experience.

Analog Gathering

Before I dove in to design messaging, I wanted to check out how other apps do it.

I use messaging a lot. When I’m communicating with others, I use a litany of messaging platforms and apps. Some do certain things better than others, and those differences determine my use of them.

It’s safe to say that when designing messaging, I don’t have to reinvent the wheel. With all kinds of messaging apps at my disposal, my next step in the design process was to look at different messaging apps and see what their strengths and weaknesses are, how they have designed their UX and UI, and what I can take inspiration from when using their designs.

Pulling analogs helped me get a sense for the current state of the industry, as well as see and be inspired by examples of helpful design and interaction patterns.

So while Slack is a ubiquitous tool in the enterprise world, what I realized was that Slack is really optimized for intra-office communication, meaning between coworkers in the same organization. And while their design is something to learn from, I believed that this model didn’t serve the needs of small businesses as much as other platforms’ design.

iMessage

iMessage is the name of Apple’s messaging platform built into iOS. Technically, only iPhone-to-iPhone messages are iMessages, but I used that name to mean the entirety of Apple’s messaging app.

Being an iPhone user myself, I use iMessage all the time, on both my desktop computer and my mobile device. So what could I learn from iMessage and how it was designed? Was this a good analog to be inspired by in my design process?

What I learned from iMessage:

• iMessage’s design is all person-centric. I find when I use iMessage, I think first about “Who do I want to talk to?” rather than “What do I want to talk about?”. That made me categorize iMessage as a people-first communication tool.

• Apple’s messaging app has been used by so many people by now that not only is its use intuitive, but it’s also been copied by many other apps:

  • Facebook Messenger

  • Signal

  • Whatsapp

• Apple’s messaging app not only facilitates intra-organization messaging (iPhone-to-iPhone) but also accommodates inter-organization communication in the form of SMS and MMS.

• The fact that iMessage is so intuitive and ubiquitous today is an advantage for a designer. With usability in mind, it would be good to use something familiar so users can jump right in rather than learn how a new messaging platform works.

iMessage was an important analog to study, not only becuase of its ubiquity and familiarity, but also for its people-centric communication setup and its ability to message out-of-network users. Studying iMessage gave me great inspiration to design VoiceEdge’s messaging system in an easy-to-use, familiar manner.

Anatomy of Messaging

While messaging may seem straight-forward to most people, there are a lot of important moving parts involved. Not only that, but a lot of apps had similar elements that comprised their UI.

In order to determine all of the different elements I had to design, I decided to take Apple’s iMessage apart and see how it worked.

I took out my phone and started taking screen shots of all kinds of different aspects of the iMessage conversations I was in. Green bubbles, blue bubbles, long messages, short messages, group threads, individual threads, you name it.

Once I had taken all of my screen shots, I used Invision Freehand, an online whiteboarding tool, to lay out all of the different elements and figure out how they work. For instance, I took a close look at the “message” and reverse-engineered how it works. What does it look like when it’s a short message? A long one? What’s the difference between a sent message and a received one? What does long-pressing do? How often does a timestamp show up? I asked all of these questions so I could understand how Apple’s designers build iMessage.

I identified the elements I would end up designing for VoiceEdge:

• Message

• Message thread

• Thread list/Thread view

• Text entry

• Header

• Details page

• New message

Initial Design and Prototyping

Once I had finished my exploratory research into other apps and weighed our customers’ needs, I was ready to design with a few things in mind:

1. I chose the iMessage paradigm of messaging over the Slack paradigm, assuming that small businesses would be better served by the person-centric design rather than the topic-centric design.

2. After pulling iMessage apart and studying its constituent parts, I would design VoiceEdge’s messaging service to accommodate the same elements but designed to fit our specific needs.

With the above in mind, I fired up Sketch and got to work.

This design for the messaging system was what I passed to my visual design colleagues to prepare for final delivery.

Visual Design and Final Delivery

I handed the above wireframes and lo-fi mockups to my visual designer colleagues to refine and align with our design system. Below are the screens they produced for delivery to the mobile dev team.

Documentation

Once design was in the final stages and not changing much, I took the time to document how the feature would work. I did this with a combination of workflow diagrams and requirements documentation in Confluence. This would be a helpful tool for our development team so they would know how the feature would behave in different scenarios.

What I Learned

I learned a lot while working on this feature. Being someone who uses a lot of different messaging platforms in my day-to-day life, it was a thrill to design a brand new messaging platform. Some of the things I gleaned from the process are:

Learn from those who have done it before.

When designing something as complex as a messaging system, it’s worthwhile to look at how others do it. Looking at different messaging platforms helped me figure out both the common elements among them as well as the differences between them, allowing me to make decisions on what I wanted to include or not include in my design.

Once a wireframe goes to Viz, things will change (usually for the better).

I had mocked up exactly what I thought was needed for the messaging platform, and even with that full delivery to my Viz team, there were significant changes when it was aligned to existing patterns and treatments from our collective style guide. This can be jarring at first, especially when a UX’er puts a lot of thought into their design, but it almost always improves the design.

Socializing a design is just as important as all the UX work.

If you can’t sell your stakeholders on the merit and function of a design, you might as well have not even designed it. For such a multi-faceted feature, it was important that I presented it with skill. I socialized this design with stakeholders multiple times over the course of the design phase, and each time came back with different feedback and questions, but once delivery actually happened, there was calm among my stakeholders since they had seen its development and knew how it worked.