How to migrate your SaaS to cloud with zero upfront costs?
Date: 29 September 2020
Time: 09:30 - 10:30 GMT
Well, UX writing is writing. Ugh, I hear you say! Writing, who needs it? You probably still feel traumatized from your experience of writing at school. You know how it went: you had to read all that old literature stuff (I’m thinking, Mickiewicz, Molière, Shakespeare, et al.); and then regurgitate it back. You probably wrote exactly what your teachers wanted you to write, and the more words you used, the better! When you wrote, you had to follow the “rules” of grammar: you had to know when to add a comma; and when to not add a comma. And, finally, there was the horror of being given a creative writing assignment, an assignment for which you were often given little or no “scope”. Instead you were simply told to use your imagination, and so this was probably the most painful task of all …
But UX writing is a bit different, because UX writing is action-oriented. Yep, UX writing is the “OO7” of writing! That is, UX writing aims to aid the user in taking the right action in a given context. In fact, UX writing is the process of creating all the copy and content of a digital experience. You may find it useful to think of UX writing deliverables in terms of these two categories:
For a long time, creating copy for the UI was an after-thought for product teams. Usually, the task of writing microcopy was an extra job for front-end developers, because, well, someone had to fill the gaps, just to release the software. But, to be honest, front-end developers were a rather good choice to have the task of thinking up UI strings. It wasn’t because they were familiar with the latest functionality, although of course they were. But, rather, it was because front-end devs were very aware of the most important aspect of UX writing, the element of context.
You know, natural, human language is a strange, slippery kind of beast:
“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean – neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master – that’s all.”
Of course, as you’d expect from an anthropomorphic egg, Humpty Dumpty was talking rubbish. In truth, with language, context is the master. With language, context is everything. We will come back to the subject of context later. Anyway, in many cases, the approach of dumping the task on the already hard-at-work front-end devs worked well enough, way, way back in the pre-SaaS era …
To answer this question, let’s think about the very nature of SaaS products.
Maybe your SaaS product solves an old problem in an innovative way. It’s great that you have a new solution! But, as you’re solving an old problem, then, by definition, this probably means that you’re fighting with serious competition in a crowded market. To survive, you must distinguish yourself by providing a top-class customer experience whenever your product is being used. Of course, a positive customer experience comes both from the fact that your software is good (the software works as it should), and from the fact that your users have a good experience whilst they use your good software.
Let’s say that you’re developing a new email marketing platform, the next Mailchimp. In this case, you don’t need to explain the value of such a platform. But, you must show (not tell) why your platform is better than all the other, existing platforms. You need a clear unique selling point (or even more than one) in terms of functionality, and great UX. The bedrock of UX is certainly good graphical, interface design. And this will suffice for short, simple, linear, limited functionality. But, beyond such a limited scope, even the best graphical design struggles to communicate a message in a way which is unambiguous. And, seriously, how many SaaS products stick to providing simple functionality? In fact, most SaaS brands are seen as innovators.
Have you noticed a subtle, but important, change in the meaning of the term SaaS? We’re no longer treating SaaS as meaning Software-as-a-Service. No, Sir! Now, SaaS means Software-as-a-Strategy, which is a quite different beastie …
The whole point of SaaS is that the product is not stuck in a rut, and that changes are easy (well, easier from a technical point of view than pre-SaaS). But, notice that SaaS is a double-edged sword: on the one hand, yeah, terrific, we, the software company, can pivot at will; on the other hand, all customers (both old, and new, customers) expect an SaaS product to be customized perfectly to their individual, and constantly changing, needs. In reality, SaaS products must provide an ever improving customer experience.
Or, maybe your SaaS product solves a new problem, because you’re a real “trailblazer”. That’s also great. Perhaps even better than just “great”. But, “better than great” means that, on a whole new level, you have to make sure that your software is super, and that your users have an out-of-this-world positive experience whilst using your super software. Plus, you have an extra problem compared to the SaaS products which solve an old problem: if you’re offering something your target audience has never heard of before, or has never used before, then you’ll need to do a lot of explaining. And, in most cases, and most of the time, why shouldn’t the user be able to operate software well enough by taking cues from within the UI itself? But, for this to happen, you need to stick to good UX practices, which includes good UX writing practices.
In part 2 of this article, I’ll describe some of the challenges in UX Writing.
Stephen Eastham, Technical Copywriter, Platform & Tools
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.