Source: Pixabay, creator: Free-Photos
User experience.
User: a person who utilizes a computer or software product [Wikipedia]
Experience: A particular instance of personally encountering or undergoing something [Dictionary.com]
User experience: the effort companies put into designing their computer or software product so that users have a good experience. [merging the points above]
A majority of hardware and software companies rightfully put user experience as the forefront of their design, planning and development initiatives. Customer-focused design that aims to test user interfaces and ensure that customer needs are met results in an intuitive experience with the product.
But, while countless books, articles and blog posts focus on user interfaces, intuitive navigation and other approaches for the products’ design, few, if any, examine the role technical communications plays in supporting users’ as they learn about a new product, just released enhancement or recently discovered defect. My premise? Technical communication makes up about 40% to 50% of all user experience elements for large firms, and maybe a higher percentage of UX for bootstrap startups or engineering-first companies.
Give me a great UI and I’ll show you a wonderful first experience; give me excellent instructions, knowledge bases and training materials and I’ll show you excellent software that helps users go from novice to power user in the shortest time possible because their questions were answered. I’ll show you loyal customers who understand how to get the most out of their products and are willing to share that experience with other customers and prospects.
I’m not stating this as a technical-writer hammer looking for a reason for employment nail. Far from it. Yes, I’m part-owner of TechWhirl, but I have a business background and thousands of hours of experience as a software project manager, requirements analyst and product manager.
I’m sharing this because when I look at a full list of activities that lead to an excellent user experience, I see that technical communication activities have to be present for just about anything more advanced than the “Yo” app. Technical communication is a key element in UX for onboarding new users, supporting existing users with product enhancements, and helping frustrated users get the most out of applications while defect-fixes are in the development pipeline.
Support New Users and Those Returning to New Enhancements
According to a 2016 article in TechCrunch that cited data from analytics firm Localytics, nearly one in four people abandon mobile applications after only one use. This article goes on to discuss how difficult it is for any application to become a go-to app for a user. These results are similar to those published by PostFunnel.Com’s 2018 article, 4 Proven Ways to Convert Trial users into Long Time Customers.
In the article, author Adebisi Adewusi covers four ways to get new users to an “aha” moment of seeing the value of your product and wanting to keep it in their lives. Those “aha” moments—the point at which they decide the value proposition of the software is greater than the cost (time, pain of changing habits and yes, money)—start with exceptional product concept and software design. But, that value proposition really comes to fruition when users are supported through good or even mediocre technical communications (good knowledge base, decent help system and a little training). The combination helps the user see how it’s supposed to work.
Think of new users as taking a journey to understand your products in order to use them to achieve some objective. They’re going to take this journey with or without your help.
The application UI may be super smooth and navigation easy-to-understand, but if a user can’t figure out which functions to use and how to use them to accomplish their goals (or in as they say product management-speak, “all of the key user cases on how to maximize the return on the entered information”), then there’s certainly a good chance they’ll never fully engage with your system. Or worse, they’ll abandon it all together, complaining loudly and at length about the failure of your system.
The user journey often starts with basic questions (how do I save my work?) that lead to more advanced questions (how do I save to a new format?) which then march on to far more advanced ways of using your product (how can I create my own ad hoc report?). Technical communication tools such as application support pop-ups, knowledge base articles, or show-me videos help various types of users answer these questions quickly and efficiently. Such results please management and bean-counters.
Similarly, technical communication also contributes to “aha” moments with product enhancements. Except that, instead of merely providing guidance to a new user, you’re also helping them alter possibly long-standing habits regarding application use. Changes inevitably set a user’s journey back, since by definition it’s something new.
And, while they won’t need another ‘getting started’ walkthrough (unless you’ve completely changed the UI and system ala Windows 8 from 7) they’ll certainly need and appreciate guidance on how to get the most out of the newish system. This presents opportunities for elements such as on-login walk-thru help screens, updates to knowledge bases summarizing the old and new approaches, and in-app reminders that gently guide users to the new features or altered workflows.
Cover Product Development Mistakes – Train Around it
The following isn’t a devops-support law, but it maybe should be: no developer can push quality code out as quickly as a technical writer can publish guidance to your user base via application help, knowledge bases, social media accounts and blogs.
No product is perfect; especially if it has any level of complexity. Bugs, defects, and UX issues materialize that require research, planning and development. Sure, you see some exceptions to the speed of a release (silly release mistakes happen occasionally), but generally you encounter some lag between when the issue is identified and it’s fixed. Curious if this hurts user experience? Just slide on over to the IOS App Store or Google’s Play store and check out those user reviews when a product update is FUBAR …
While your technical authors create and nurture trail guides for new releases, in defect land they serve as clean-up crew for UX. Authors who participate in the planning meetings can learn about issues and devise ways for users to mitigate the issues. The product team can “train around it” to give some cover to the devs while they sort out the issue. It’s not a perfect solution, but in the world of user experience, support materials beats doing nothing at all.
Here’s another proposed devops support law: technical communication should never be a substitute for teams working to create a great product (UI, feature set, etc). Show me a terrible product with great support and I’ll show you, well, a terrible product with terrible UX. Technical communication serves best when it supports wonderful UI and UX design, instead of trying to provide endless cover for its gaps and flaws.
Conclusion
I was taught in business school that not having a strategy means that’s your strategy. In the same way, not focusing on technical communications in your UX strategy means you’ve decided to let those new and returning users go through the jungle without a compass and a machete, rather than steering them to an easy-to-follow path.
The user journey from brand-new to power-user includes a long list of questions that need to be answered and occasionally re-answered. The question I have for you is – are you focusing as much on that techcomm UX as you are on the graphical UX? And, if you’re not focusing on it, are you—and management—comfortable leaving valuable opportunities to create “aha” moments on the table?
