Using User Research To Restructure the Information Architecture Of A Billing Software And Improve App Navigation:
Communication Tools for Sonar Software
Project Background
Originally, this project revolved mainly around Sonar’s “Triggered Email” tool, which allowed users to set up specific email “messages” and have their sending be “triggered” by certain events (eg. when an invoice is ready, when a new account has been set up, etc.). Setting up Triggered Emails and using it required the user to visit at least 3 different pages, all hidden in the Settings menu. This project was meant to address this and be purely an information architecture rethink. However, once I started looking into this more, we realized that not only did Triggered Emails live somewhere awkward, it also had an awkward workflow, and despite being seemingly related to other communication-related tools on the app, they all existed as separate features in their own areas of the app, some in Settings, some in Ticketing, some in Accounts.
Gradually, the scope expanded to us rethinking the relationships between (or, rather, the separation of) our existing communication-related features, and how we could make these areas not only more accessible, but how we could meld them together into a more cohesive “communications area”.
Project Objectives
Key Tasks & Responsibilities
Improve and simplify the workflows (setup and maintenance) of communication-related areas (specifically, “Triggered Emails”, “Mass Emails”, and “Canned [ticket] Replies”).
Make these features easier to find and more obvious how to use.
Understand the mental models of our users. How do they think of these features? Which do they see as related, where do they expect to find them, and which features do they need access to more or less often?
Unite related features where possible. Don’t allow some features for one tool but not another.
Add communication-related features that users are asking for.
All research and design related to this project.
Presenting research findings, takeaways, and design solutions to product management and development teams.
Overseeing and approving decisions related to the many design changes due to technical limitations and requirement changes during the development process.
Research
Example of card sort data analysis (the tool we used didn’t provide analysis, so this was done manually).
Example of user feedback database.
Example of survey response database.
Example of card sort data summary.
Part of our motivation for taking on this area of the app was due to the many feedback requests we received about our various communication-related tools via platforms. We collected this feedback from various sources, including our feedback portal (powered by Pendo) and client-facing staff members.
Once we’d identified an interest in these features, we sent out a questionnaire to customers who had submitted feedback or interacted with these feedback items in some way. Via this survey, we also managed to recruit various participants to complete a card sorting exercise, which we hoped would allow us to better understadn our users’ mental models when it came to these areas. What did they see as related features? What do they see as a “setting” vs. a feature they want access to more often? We identified a similar problem with the Scheduling area - many key features were hidden in the Settings on various pages. I decided to kill two birds with one stone and provide participants with terms related to both scheduling and communication features, and hoped that this give us a more realistic analysis of the app as a whole. Then I would be able use the data to inform this project as well as future projects related to Scheduling.
Finally, I also used click and visitor data from Pendo and Hotjar to better understand which features were being visited more often (and probably didn’t belong in the Settings menu), and which were more “set-it-and-forget-it”-type features (and could stay in the Settings). We also used this data to determine common workflows and which features were typically used in conjunction with one another, as well as the order in which they were used.
Key Takeaways: Which Problems Do We Need To Solve?
The current workflows feel clunky and unintuitive.
The functions and configuration are not easy to find or obvious how to use.
Some parts of workflows like Triggered Emails feels redundant.
Many users see many of these areas as related - Sonar should introduce a new app area that houses all of these features.
Some features have functionality that users would like to see on some of the related features.
Ideation & Iteration
Proposed Solution:
Create a new app area called Communication Tools, which will provide access to all message types (triggered, mass, and a new type called “single-recipient”, as requested by customers).
Introduce SMS functionality as requested by customers. Offer this for all message types - change wording from “email” (eg. “mass emails”) to “message” to account for this.
Leave “Set it and forget it” features in the Settings menu, as identified by card sort data.
Introduce a new button to Communication Tools called “Configure”. This button provides access via a modal (to avoid interrupting underway workflows) to features that were once hidden in Settings, but that users interact with more regularly.
Introduce additional features requested by customers such as message previews, ability to send test messages, ability to create messages that can be saved as drafts and used across message types, etc.
Example of research and design recommendations.
Above: Example of one of the suggested user flows mapped out for this feature, which combines the Mass and Triggered Email tools and provides access to a “Manage” (later named “Configure”) button from anywhere in the flow.
Above: Examples of some of the early sketches of this feature.
Above: Walkthrough of various Create Message forms.
Above: How to save a drafted message as a new Saved Message, how to send and send test Email and SMS Messages.
Solution: Where Did We Land?
How Does It Work?
A “Communication Tools” area was added to the app’s main navigation menu. From here, users would be able to access both the previous “Triggered” and “Mass” email features, as well as additional access to the new “Single Recipient” and “SMS” message features.
Users can access a “Configure” menu from anywhere within Communication Tools, where they can view, create, edit, and delete various entities related to sending messages. This allows them to make changes and view these entities without having to navigate away from their current workflow, as they had to previously.
From the main landing page (left: consistently a table, as with all other app areas), users are able to create and send or enable new messages in the format of their choosing.
Each “type” of message would support 3 drafting views: Email, SMS, and Both. Each form was designed to mirror the others as closely as possible in order to improve learnability and recognition, differing only where necessary to support varying functions. Similarly, the Email and SMS versions of each message form were designed to be as close to identical as possible. This would aid in form completion, especially when in “Both” mode.
One of the most notable features added was Saved Messages - messages that could be drafted via any of the message forms, saved, and used for any of the message types in the future.
Some other additions were the ability to create and attach different Signatures, preview messages, and send test emails.