Originally was going to the session about DITA, but again, it was in the room with no tables. Also saw a session on API docs, but it turns out it wasn't about creating them, but about how to use a specific too. So I wound up in this session, by Laura Bergstrom of Microsoft.
Which all meant I got in a bit late and missed the opening remarks. So I'll catch up as best I can.
The language in software interfaces is about building a story, about developing a "voice" based on branding. An end-to-end experience team works on the whole process, from high-level messaging and stories down to guidelines and catalogs of assets for messaging and design.
Some early steps include scenario-based engineering and writing, the value proposition for customers a "listening tour" with the leadership team, and looking at trends into the near future.
The goal for scenario-focused engineering is customer-focused. Planning, designing, and building is a daily iterative process. What they call "scenarios" looks very similar to personas. Scenarios are important because technology changes, but people don't. It give you understanding of users. When yo focus on what people value, it drives innovation. Also, you can predict what users will and won't do in a situation.
Use a story structure to create your scenario.
It takes more time to write something in a friendly tone than by pre-set guidelines. A good tone is friendly, empathetic, everyday language.
It's OK to use contractions. It's even encouraged. Use them when it feels natural, but dont' force it or use uncommon ones. Ask yourself "does it sound harsh" if you don't use one.
Use second voice, even in the UI. Speaking directly to the person can be very friendly.
Why have a dedicated resource for UI content? Well, a user assistance developer (writer) is trained in the subject. They understand conceptual models. They understand user empathy. Yet they also have deep experience working in an engineering environment. And taxonomy, style, and so on will be consistent. It's a good argument for not letting programmers or managers handle the task. Dedicate the proper experience to the task and your users' experience will be much, much better.
Conversational tones are harder to translate.
Tone matters because people want to scan, not read.
No comments:
Post a Comment