This content originally appeared on DEV Community đ©âđ»đšâđ» and was authored by NoÄnica Fee
Recently I had a chance to talk to DevOps
Minneapolis about the true nature of user experience. The audience found this information to be particularly interesting, so I thought it would be helpful to share it with a wider audience. This post will be the first in a series of three posts that will discuss user experience beyond your appâs UI and how you can optimize it.
So where is your user experience? More generally, where does your application happen? For those of us who work in SaaS, the answer is simple: the application occurs inside the application interface. Whether weâre selling business tools or teaching Spanish, the application happens when our users access the UI.
Your UX is inside your application⊠right?
When we talk about our users having a good experience, that much-vaunted UX, the things weâre tweaking will be inside this application. We have several specialists who worry about user experience. Whether thatâs UX thinking about existing users or data and product people making sure the experience for new users is frictionless.
I donât mean to trivialize this process: itâs much more than tweaking colors and moving buttons by a pixel. Those tasked with UX often have to ask the most basic questions: what do our users want, and whatâs the best way to give it to them? This matters because however cool our technology is behind the scenes, if the user doesnât have a good experience with it, theyâre unlikely to return.
This article argues that thereâs a more important user experience than the one inside your app. In fact, your app has a whole interface that has more impact on your users, that touches them more deeply than your application interface.
Itâs your notifications
This is where your notifications really happen.
Many of our favorite apps largely interact with us through notifications, the examples are everywhere.
- Tools for observability and security most frequently have all our interaction starting with notifications. After all, we're probably not checking our APM tools until we know something is wrong.
- For social media applications, the best moment we experience with them is seeing that X number of people loved our post.
- And for communication and collaboration applications the notifications should have most of the information that people want you to see.
In fact, Iâd argue that for many of our most valued tools and services, most of our interface, for good or ill, is through notifications. Notifications bring you into the application. They provide reassurance, warnings, anxiety, or annoying notifications about sales of pizza. Notifications are your application.
I mention all this because I believe that your UX is in danger. Primarily, the experience of notifications has been ceded to teams outside of the product team. Instead of our product team controlling notifications, itâs the operations or marketing/growth teams that control most of the notifications we send.
Let me show you far we have strayed from g-dâs light:
The tale of the signup campaign
The time after a user creates an account is critical for any SaaS tool. Even when users sign up and immediately start using the product, there will be features or extended use cases that we, the developers, want them to try.
Put yourself in the shoes of a product team thatâs trying to improve the rate at which new sign ups become committed users. In (almost) all product teams, weâll realize that we want to get in touch with users after they sign up to encourage them to keep going with our product.
The platform doubtlessly sends a signup confirmation, and we start by tweaking that. We get our new copy and links to the operations team, or platform dev, and they change the post-signup email. But soon, we want more. First off: we donât really want to email users the instant they sign up, weâd like to wait at least a few hours, to let the platform feel a bit familiar first. Then weâd like to follow up after a few days, and a few days after that.
Even better, we, the product team, would like to customize these messages a bit, depending on their team size, what license they have, etc.
The operations team, who implement all outbound notifications, is rightfully a bit frustrated by this. Theyâre used to solving bugs and feature requests for the platform, not tweaking an email. Scheduling? Audience customization? This sounds like a job forâŠ.
The CRM, where for a time it was good
With all the need for custom targeting, a good first solution is to have a signup get sent as an event to a Customer Relationship Management (CRM) tool like Salesforce. From there, itâs easy to start a âsignup campaign.â Since the CRM should know things like the org size and license level of the user, the messages can be nicely customized.
And for a time, it was good. However, trouble starts when we go one step further with targeting and customization.
You see, our signup campaign encourages users to use certain features, like say Reports Export. We want to tell the users about the feature, demo it for them, walk them through the concept. âPleaseâ our emails beg, âexport your reports, with the Reports Export.â
This message will seem super weird if the user has already used Reports Export. So we, the product team, go to whomever runs the CRM and say âcan we cancel this email if theyâve used Reports Export.â Of course, the CRM doesnât know that. So we end up back with platform engineering, asking them to send an event to the CRM when someone first uses Reports Export.
The âquick and dirtyâ solution of CRM wasnât a durable solution to our problem.
The problem is a ceding of territory
The inherent problem in the scenario above is a ceding of territory by the product team. If the product team wanted to move a button, or change the order of a toolbar, it wouldnât make sense for the marketing team to say âno.â But when we want to send a correctly targeted sign-up campaign, our reliance on our CRM means Marketing has to say ânoâ to a better user experience.
Similarly, we wouldnât let ops or platform engineering keep us from adding a helpful tooltip, but we are letting them keep us from sending a helpful email to the right users.
What we can do to solve the problem
The problem here is a lack of tooling, either external or internal. Every new notification stream requires engineering time, and that means technical limitations keep us from delivering the experience our users deserve.
Whether itâs by using Courier or an internal spike to create a messaging microservice, you want to develop a robust set of features that make it easy to send multiple notification types direct from your platform.
This content originally appeared on DEV Community đ©âđ»đšâđ» and was authored by NoÄnica Fee
NoÄnica Fee | Sciencx (2022-09-07T15:58:38+00:00) Building a Great UX Outside of your App. Retrieved from https://www.scien.cx/2022/09/07/building-a-great-ux-outside-of-your-app/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.