At POP chat conversations power the platform. Every feature revolves around it and therefore conversations should be easy to create, edit and save. Just like Microsoft Word or any notepad app, POP needed an editor: a chat-editor.
The goal was to design something simple and familiar without losing the ability to create advanced conversations such as surveys, quizzes, chat forms and more.
September 2016 — Now
When I joined POP there was no editor. I helped create the very first one (just an input field where you can enter 1 chat message) in true MVP style.
The platforms clientele was exclusive social media managers for music artists. To allow for more creativity than just 1 simple text message, we started designing and building our first editor.
The compose screen to send a message to fans.
These are some of the principles that came up in early discussions. At the time competitors had noodle-based user interface. Where you would create blocks of content and you had to connect them together (often with lines or arrows). Sometimes for very simple promotions the converstaions seemed overwhelming in the editor.
It must be straightforward and easy to create a simple conversation.
Follow the ‘top to bottom’ principle of a regular chat. The first message is at the top of the chat, the last one at the bottom.
Advanced features are important, but secondary in our editor.
A still of a prototype where a 'block of conversation' is embedded in another conversation.
A view of a conversation showcasing merchandise in gallery cards.
This first version of the editor supported 3 different components used in Facebook Messenger): text, quick replies (buttons that appear underneath text messages) and gallery cards (larger cards with image, title, subtitle and button). It was designed in the same style of our dashboard to match the look of chat apps at the time.
A view of a conversation showcasing results after asking a multiple choice question.
This first version the editor however was only available on 1 particular page. Along with a refreshed design of our dashboard, the decision was made to make the editor available on all pages, via a pop-up like behaviour similar to common email apps.
This way any page in POP could launch the editor for a quick edit, save and continue your way flow. A good (architectural) decision that still works very well today.
A video demonstration of the chat editor in action.
More recently I have made different explorations as to how the editor could evolve and solve the issues with it.
We definded the issues as such:
However, before I started on any of the details, I wanted to be sure the team/company was still set on continueing the current style of editor. To communicate the pros/cons of every different editor I printed out editors used by products such as Notion, Gmail, Manychat, Dropbox Paper, Medium, Wordpress Gutenberg.
A big argument for the type of editor chosen is that is really adheres to the principle defined above: to be simple first, advanced second. Plus some editors really wouldn’t work on tablets or mobile devices. That was something we did not want to rule out at this stage.
To tackle each one of the issues I started sketching very early on. When encountering these issues in the past I had continually made notes of them and sometimes discussed them with engineers as they popped up. The list was not foreign to me when I started this project and that helped a lot.
We are not saving on the ‘editor level’ but only on ‘component level’. This causes users to feel like they can make a change and discard it, but in fact we always save a change.
This issue is easy to adjust with design. A more obvious ‘save changes’ button up top along with version history (in a future iteration) would make the mental model of our customers match the editor.
Displaying 'Save as...' under 'More' as an option alongside a prominent 'Publish changes' button.
A detail from the version history indicator.
Certain components have grown in the amount of features or options they provide to the user. This causes both UX and technical issues where the pop-over to edit those options becomes very large.
To combat each component displaying generic options to update a user's subscription, segmentation or other data, a solution could be to provide 1 'data update' component that would be invisible to the end-user in chat, but would handle all data updates.
Another bonus would be that in the editor itself, it is now obvious where data is being changed. Rather than it being hidden in certain components that also serve a visible in-chat function.
And instead of opening an enormous popover, the editor could expand like an accordion to make room for the component’s options and settings.
This image highlights the problem: even a simple quick reply button that is commonly used has a lot of functionality.
A generic, non-visible in-chat component to serve all data updates.
Instead of opening a popover, the properties and settings of a component could open in an accordion style to not overlap other components.
A protoytpe highlighting the experience in the editor of opening the data update component. For prototype purposes this data component opens with 1 property already selected.
It is possible to write a conversation in the wrong way and having to delete your work and start over. This is also due to certain restrictions that limit the user in the ability to re-order components.
Reordering components was a true puzzle when we first got to introducing components with restrictions. For instance, the quick replies component must always have at least 1 message in front of it. You can not start a conversation with it.
This creates al lot of cases to handle in the editor:
Due to these restrictions, it was sometimes possible to write a conversation in the wrong way, realize this, and then decide it was better to write it all over again.
Because the restrictions are set, a possible solution to make the editing process smoother could be to be able to ‘group’ the messages in blocks, and then ‘explode’ that block again. This way you can move larger pieces of conversation around, without the limitations.
A prototype of the various hover states on components and the ability to select, group and ungroup multiple messages.
A growing number of components.
The growing numbers of components is mostly fixed by re-ordering and merging functionality across components. For instance almost all of our components allow a user to be added to a specific segment (a group of people), it would be easier to create 1 component for adding people to segments instead of duplicating the feature for every component. A simple improvement.
The issue: too many components to choose from.
A prototype of the new picker in it's basic form.
An idea where on hover you see a small preview of the component you're about to choose.
In the situation where the component library would grow, search could be introduced.
A lack of help in the editor.
Even though the editor has to be as intuitive as possible, it will always have people not fully understanding it’s functionality and experience bugs. Therefore it should be easy to find help in the most advanced section of the product, without leaving the editor.
To make help always visible, in the bottom right corner a small question mark is displayed at all times. This opens the help sidebar and from there, resources and help is just a click away.
Some mockups to present and showcase the editor with members of the team. Along with in-person talks I shared various prototypes in Slack to get other people’s perspective and thoughts too.
A mockup highlighting various states of the editor user interface.
A mockup showing the creation of a conversation screen.
A mockup showing the mobile editor user interface.
A mockup showing the editor with multiple messages.
The editor has proven to be a very fundamental feature of POP and I’m happy it’s foundation is still solid and working well.
I’m also proud of the process the engineers and I went through to provide valuable improvements to real problems customers face. Though we haven’t been able to ship everything, the ideas here are a really good evolution of the editor.
Foundational design principles for the chat editor
Different components in the chat editor (and growing)
Iterations, additions and changes to the original chat editor
Press M to unmute audio