Use cases on UI/UX writing (+ Designer’s perspective)
The article will guide you through three examples of writing challenges related to design and the Designer’s role in it. Based on lessons learned, I included the section with key takeaways and tips that might help you minimize a handful of issues on your way. As a delightful extra, recommended UI/UX writing books are waiting for you! 😊
While working on any kind of content, I bet you have doubts about its purpose. Isn’t the functionality obvious enough for users to understand its principles and processes without documenting? That’s the thing — not always. User interviews and surveys confirm that ways of using a product or service are sometimes not as intuitive as they might seem, notably with complex software systems without sufficient documentation. To add to that, there can be discrepancies between the interface and accompanying text guidance. And here comes the collaboration with the UI/UX Designer.
The UX of your app or website handled by Designers goes hand in hand with what Technical Communicators write. The foremost principle for both is to listen to your user’s needs, especially if implementing a new approach or fixing the existing one.
Case #1. Starting collaboration and user interviews
Once, I had a task to update the information architecture of a knowledge base and add guides. For the changes to be well-done, user feedback at the initial stage was a must-have. Together with the Designer, we decided on the format of UX research, which involved conducting meetings with users, and agreed to prepare questions with explicit materials to walk them through the path.
The issue we encountered at the start was about scheduling and target dates. Our misunderstanding of the collaboration process and other high-priority tasks on the Designer’s plate hit a snag. In detail, none of us defined the exact time for communication and just talked on the spot, not to mention the dedicated time for reviews and preparing a mock-up.
After the first interview, which was efficient anyway, we stepped back to organize our internal processes better and set dates for the desired milestones and results in written form. Toward here, the Designer and I have managed to define the most relevant topics for calls. We supported and complemented each other while having dialogs with users about the pain points they encountered in their working environment, convenient ways of navigation for getting started, and appropriate labels for buttons and tabs.
So, the Designer and I climbed the mountain and excellently conducted interviews because of restricted timeframes and conclusions about the content to come into sight based on predictive UI algorithms that users expected.
A side note: talking to your users regarding the content is a fantastic and vital experience that reveals many pitfalls. Usability testing not only defines where the product can be boosted but also where the documentation can be improved. Moreover, a positive attitude is guaranteed in most cases. Please, do not blame me if not! :)
Case #2. Being actively involved in the process
You and the Designer must know the product well. Let’s look closer at the related case I had about microcopy (messages and other text types in the UI).
When you direct your efforts to a copy, the cornerstone is clarity, consistency in voice and tone, terminology, and style. If you are new to a product, the Designer stands for a key contact point who might primarily assist with understanding established copy patterns. Since I was commonly engaged in warning and notification messages at the beginning of my assignment, I started with preparing two or more versions of a message for the Designer. This way, they could provide arguments about what works best and why.
Though, if the Designer is at the beginning of the product’s learning curve, take the initiative to understand the main workflows. Exchanging experience is a fruitful step toward business targets.
Case #3. Representing information visually with presentations, one-pagers, diagrams, and infographics
Now, allow me to share that Designers typically research user segments and can flesh out the details in addition to your findings while dealing with the audience analysis. The same relates to UI trends and rules used for the visual representation of your information. For instance, thanks to the collaboration with my Manager, who has experience in UI/UX, we have been successfully integrating content and design while describing factual business aspects and the project services not in a strict text document manner, but with presentations and infographics.
Exchanging insights in our fields and considering each other’s ideas was a winning strategy.
Some examples of what I have learned so far:
- You can focus users’ attention on the noteworthy content by applying accent-colored shapes to certain areas. Make sure to reflect the visual hierarchy of data and have a convenient data reading flow.
- You can arrange layout blocks in an obvious to our eye scheme rather than an exquisite or sophisticated one to make content representation impressive. Simplify where possible.
- Having less information per slide facilitates perception. Reduce clutter and mental tasks by removing items from your visualization rather than adding something to it.
As a Technical Communicator, I also gained best practices in defining applicable illustrations or elements and many more.
By working together, UI/UX Designers and Technical Communicators form an aligned, continuous, and user-friendly experience for a straightforward product journey both in design and documentation.
Key takeaways for Technical Communicators in the UI/UX area
Organizational tips
- Designers and the rest of the team might be out of context of your work. If so, take time to explain what exactly you can help with and why your input will make a change.
- Join the product team chat that includes Designers to be in prompt touch with them when it comes to user surveys, UI/UX feedback, and the latest product news and updates. If there is no such chat, create yours in any communication tool.
- Prepare the schedule of your cooperation with the Designer like weekly sync-up meetings for 30 minutes and status checks on Wednesdays, for example. Do not take the approach “when you have time, let’s do this” because there might be other QA, development, or product-related tasks for them to finish, and the documentation will take a lower priority.
- Communicate every step and area to discuss during calls or surveys with users. Speaking about topics to be located on the home page, try to stick — both you and the Designer — only to the relevant questions to your interviewee.
- Keep in mind business targets and resources. If your teammates propose controversial changes, reach a consensus on the appropriate solution.
- If possible, create a mock-up to visualize your ideas for users. The mock-up will facilitate perception.
- Prepare a list of interview or survey participants and arrange meetings or messaging with them.
- When on users’ interviews, listen to the terminology they use about the product. The existing naming, labels, and approaches might be questioned.
- Take care of meeting notes or recording if users allow it and summarize your research in one place, like Confluence space or SharePoint docs.
Content tips
- Think about accessibility. Consider the level of perception, information processing, and interpretation based on ease of use. The better your chosen format of content fits specific audience needs, the more proficient it is. After all, we present information in various formats today, not only written. Videos, audio, and graphics stand in the same league. Designers, on their part, might help you with design patterns and color choices so that the product is comfortable for individuals with low vision and others.
- Ensure content compatibility on all possible devices. Buttons with text labels or tables with big data must be visible and clickable in all extensions. Shorten the number of words if needed — be succinct.
By and large, addressing and resolving the issues users struggle with is the fundamental purpose of documentation. And UX/UI Designer remains your BFF in this subject. :)
Oh, just about missed! Creating documentation covering pain points reduces support inquiries and saves resources for the company and the users. Visit Seven myths about Technical Communication and What is the business value of having a Technical Writer on a project? to learn more.
Additional: books for UI/UX writing
To expand your understanding of this topic, I can recommend these three books:
- Writing Is Designing: Words and the User Experience by Andy Welfle and Michael J. Metts
- Microcopy: The Complete Guide by Kinneret Yifrah
- The Non-Designer’s Design Book by Robin Williams
More on 7 books for Technical Communicators.