As Information Developers, we need to perfect the skill of writing well, and the scope of our writing is not limited only by creating technical instructions. We should be equally good at creating web content, articles, or blog posts. Besides, one day we might even need to write some sort of a document that we have never dealt with before, for example, a business report or promo brochure. In this situation, we can spend hours googling and processing tons of contradictory or ill-structured information. Or, get our hands on the book “Be a better writer. Tips to improve your writing – no matter what you write!” by Suzanne Lieurance, saving us time and giving us quick directions.
What use cases are
A use case describes a sequence of interactions between a system and an external actor that results in the actor being able to achieve some outcome of value (Karl Wiegers and Joy Beatty “Software Requirements”, third edition, August 2015).
Technically, these are requirements specifications resulted from a thorough analysis and a number of discussion iterations with Product Owner and the development team (software architects, most probably).
Use cases give all parties (Product Owner, development team, as well as technical communicator) a clear overview of what functionality and interaction types between actors and a system will be implemented. The textual description of such interactions provides a precise picture for a Product Owner and other stakeholders that shows what their solution will be in line for and how exactly it will be happening.
Within the roles performed in the team that is involved in development and delivery of a software product, designing and writing use cases is the task of a a requirements specialist.
And you, an information developer, should understand the true worth and value of use cases on a project and try utilize them to the fullest extent.
I waved the beautiful seaside country goodbye, unpacked my trunk, boasted my tan to everybody I could, and… met the first Monday of my post-vacation life.
In order to successfully leave the laziness bliss without getting hit on my head with the reality crowbar, I tried some simple steps on the way back to the working routine.
You can say they proved to be effective as today is already Wednesday, and not a single thought on wanting more vacation crossed my mind yet🙂
All technical writers struggle to develop documentation that would be easy to digest by both advanced and novice users. Nowadays, when a 5-year old can download a game on Play Market, start it, play unless getting bored, and delete it, and a 60-year old can get confused by the amount of freezer controls located on the dispenser panel, it’s an uphill battle. We do have to write documentation that would suit both types of users.
Warning! I come bearing no answers. Just putting some questions you may find not comfortable facing.
Problem statement: you know all the best practices. But your result is far from being best.
One of the things you need to give a thought to when preparing the docs is the user data that will show up on your screenshots and in your examples.
A very straightforward and down-to-earth example – the sign-up functionality for a website. Let’s take a very common case like signing up for Twitter.
In the previous post, we discussed who user personas are and why they are important for Information Developers, considered key elements that should be included into a persona card, and reviewed a user persona sample card.
In this article, I will provide steps on how to create user personas, share some practical tips, discuss how Information Developer can apply user personas, as well as give references for further reading.
“Personas are a way to give the user a seat at the table every time.” Kendra Shimmell