Messaging interface
The project
Brief and key objectives
- Create a new instant messaging interface on site to improve the platform's network features (related to the newsfeed project).
- Phase the messaging system to gradually replace other on-platform contact processes.
- Keep users on site for longer, and keep them returning.
- Provide more value for paying users.
Deliverables
- MVP messaging interface
- Email notifications
- Launch email
- Product tour
- Feedback survey
Key tools and skills
- User surveys
- Wire-framing
- Prototyping
- Email templates using Brevo
- Feedback collection and monitoring
Why a messaging system?
User research
User research and customer requests had told us that both media and brands wanted to see an on-platform inbox, and the demand had been there for a while. As we were focusing on the bigger picture of creating a network effect, it was the perfect time to implement this feature.
Results from part of a feature prioritisation survey
Deciding on the MVP
Phasing the messaging system
We have big plans for the messaging system, and in future would like all of the platform's features to integrate seamlessly with the messaging feature. But to begin with, as a product team, we decided that phase 1 would consist of a basic messaging system where users could exchange images from the image library, as well as files, with further phases allowing more integration with other core features. Keeping it fairly simple for MVP would allow for better quality, more polish, and more thorough testing... but we would quickly ship further phases after launch.
Including message requests
Controlling spam
One thing we were very cautious of when adding a messaging system onto the platform was spam. It's great for our users to be able to communicate with eachother on site, but adding messaging without restrictions would risk users being bombarded with messages, or receiving unwanted messages. We decided that message requests would at least help to control this issue for now, and then after launch we could assess how the messaging system was being used, and could consider introducing other outbound messaging limits if we needed to.
I put together a message requests flow chart to explore and communicate to the dev team how I envisioned message requests to work. We'd then work together to iron out the finer details.
Deciding on a collapsable menu
Page structure
By looking at multiple other messaging platforms and assessing our own requirements, I came up with a basic idea of how I wanted to structure our messaging feature. But I had multiple ideas for splitting out different types of messages...
This concept displays the message types at the top, with the client drop down (agency only) in the top right.
We decided that having the inbox menu items down the left-hand side would better future proof the page for more additions.
Collapsable menu
The main potential issue that arose from having an extra level of menu on the left-hand side was losing real estate, especially on smaller screens. This was when I decided that we could implement a collapsable menu to allow users to free up screen width if they chose to.
Prototype showing the collapsable menu animation
Design examples
Below are some of my designs for the messaging interface on desktop.
Conversation list and message previews
Below are some of the different states for the message previews in the conversations list.
Sending images
One of the platform's core services is the image library, so it was important to consider how these images would be sent to media, and how media would receive and download them. We had an existing image selector modal that we could use, but we wanted the image selector to feel like it was really seamlessly integrated into the messaging feature. This would make it really easy (down the line) for brands to respond to media requests.
Receiving images
Downloads and coverage are an essential part of a brand's experience on Press Loft. Ultimately, the more downloads they receive, the better their experience, and this often goes hand in hand with perceived value of the service. Therefore, the download experience for media receiving images from brands had to be simple, but we also wanted it to feel similar to their download experience in the image library.
Image library attachments
When images are attached from the user's image library, the media member receiving them will be able to click on the image, and the image details page will open in a new tab. Alternatively, they can click the 'download' icon or 'add to download folder' icon, which function in exactly the same way as they do in the image library, providing media members with a familiar experience.
Uploaded images and files
Uploaded images and files will be treated slightly differently, where they will have a preview function, and the download function will not trigger the download details modal (which is required for image library downloads).
Download all
When hovering over a message, users will see all actions relating to a message. From here, users can download all files from a message. This UX was inspired by Slack.
Message requests
Below is a basic example of what a received message request might look like.
Responsive designs
Mobile and tablet page structure
The mobile and tablet designs would have a similar look and feel, but would be split across two screens. The main conversation list uses horizontally scrolling tabs so users can flick between different message types without leaving the page. I then used typical mobile messaging UX, where tapping into a conversation takes the user to another screen with that conversation. Features like image attachments use the whole screen to allow for easier image selection.
Messaging CTAs across the site
In phase 1, brands will be able to message media from their profile page. They'll see media members' profile pages when key actions are taken by them. For example, if a media member downloads a brand's images, they will be able to visit their profile and send a message.
In phase 1, media will be able to message brands from the brand directory and from their press office. This will replace the current 'Contact PR' function which opens a modal where they can send an email. We'll then quickly implement more message CTAs across the site where suitable.
Integrating the messaging system with key platform features
The initial messaging feature (below, left) will include these inboxes:
- Main inbox
- Unread
- Message requests
- Drafts
- Archive
Future phases (below, right) will include:
- Inbox to manage collaboration responses
- Inbox to manage media request responses
- More filters and improved functionality around managing these responses
Notifying users of messages
A new notification system will be coming soon, but until then, we'll notify users of their messages by email. They will also be able to decide in their settings whether they receive real-time message notifications, or daily / weekly summaries of messages. Below are example email templates for these notifications.
Measuring impact and iterating
This project is in progress and is in the build phase, but the following steps will be taken after launch going forward.
Areas of importance to monitor
- Message requests and numbers of messages sent
- Potential spam
- Image downloading and interactions
- Profile interaction
- Blocking
- How the product is used on different devices
Collect feedback
- Run user testing and feedback sessions with users once the feature is live
- Introduce the product with Intercom tour points (and launch emails) and prompt users to leave feedback
- Include a feedback link within the interface
Observe usage
- Observe user recordings on Hotjar
- Use device-specific heatmaps to see where users are engaging
- Use Google tags and events where appropriate
- Use Redash and our own reporting system to monitor usage levels
Implement further phases
- Implement further phases of the messaging feature
- Integrate the messaging feature into more areas of the platform
Iterate
- Continue to iterate based on feedback and observations