Information Architecture for Complex NGO Service Design Operations
How I built a team to create and manage large volumes of disaster program content for critical user and service design touchpoints using plain language, trauma-informed design, and accessibility.
If you’ve worked for a large organization with thousands of employees and multiple lines of business, you’ll quickly see how important it is to communicate clearly and concisely. Avoiding confusion and achieving positive outcomes is an objective for all design forms. This is true for both the work you do internally and with external partners and clients. Cutting through extraneous details, deciphering what’s really being said, and determining how to communicate consistently is an important skill for everyone. Especially designers.
Unnecessary Complexity Makes What’s Difficult Even Harder
While working at a non-government organization focused on disaster relief services, I observed teams working with complex content filled with acronyms, abbreviations, and inconsistencies with how words were used and communicated. I found that most of the content was so complicated that I needed to read it multiple times. Often it still didn’t make sense or worse, created unanswered questions and additional confusion.
Complex content is a pain point for readers trying to comprehend critical information. I knew that if I felt this way sitting in my home office with a cup of coffee, a person under stress in the aftermath of a disaster would struggle. They would certainly have a poor experience with the related service touchpoints.
Often overlooked but extremely important, the words we use and how content impacts the client experience is a huge part of service design.
Image Credit: Her Creative Studio
On this Page
There’s a lot of work I’m proud to share. Continue to browse through or go to a section:
Seeing a Major Need and Service Design Opportunity
Building a Team
With so much content needing attention I saw an opportunity for my design practice. I established a UX writing team to work with me on content as part of the design process. We also worked to educate and help stakeholders during their own content creation. Further, it helped me solidify even more buy-in for the value that user experience and service design brings and the many ways that intentional design makes a difference:
- Plain language clearly communicates during disasters and times of stress.
- Incorporating warmth and empathy into writing helps people without making it feel transactional.
- Provides equal understanding and access to everyone.
- Supports people through clarity and simplification.
- Builds trust and positively represents the organization’s brand.
Content Creation Workflow Diagram
I created this workflow diagram depicting all of the different roles involved in the content creation and editing process through translation, approval, and development.
Leveraging Prior Experience
To get started, I first drew upon my prior experience. At one point in my career, I spent time working in eCommerce with writing, designing, and developing email marketing. I also worked to research customer search intent and optimize public-facing sites for search engines to improve conversion rates. This new adventure built upon my skill set. I am proud to have built a new, first-ever content design team in the organization. Here’s how I did it.
Plain Language Refresher
Slide from Presentation What is Plain Language?
Plain language focuses on helping an audience to read and comprehend any content quickly and easily. It’s clear and concise.
Slide from Presentation Plain Language Benefits
Plain language is user-centered and trauma informed, helping everyone understand content with ease. Writing plain language takes a lot of effort.
Plain language and simplicity go together in design. Knowing that I would be creating resources to educate others about what plain language is, I refreshed myself with plain language so I could communicate accurately about the topic. I read federal plain language guidelines, attended training, and reviewed before / after examples in the federal digital space. I also created a presentation to deliver internally to stakeholders not familiar with plain language.
Recruiting and Onboarding Writers
Since there was a large volume of content to be worked on across multiple teams, I knew I needed help with the workload.
I first outlined specific skills to attract candidates. As part of the interview process I approached the conversations with openness about the work we’d be doing together and how it was a brand new team. I am fortunate that four professional writers joined me on this new adventure with their talents.
To begin, I envisioned how to design the onboarding process for my new writing team. I created an onboarding package to share with them over the course of a few weeks. My onboarding materials were designed to build on the previous topic from the week before. It was important to me to give a warm welcome and set them up for success.
Slide from Onboarding Materials About Areas of Focus for High-Quality Design Standards
As part of the design process, the team produced high-quality work for the public through research, standards, testing, and iteration. Language is part of everything.
Slide from Onboarding Materials to Share Your Input on Team Norms and Core Values
One of the first activities I had the team do together was create an outline of team norms and core values. New team members contributed to it also.
Onboarding Package Topics
Weeks 1–2
- How UX Writing Fits Into Organizational Goals
- Our Product Team
- Product Background
- What is Service Design?
- Service Design “Zoom Levels”
- What is User Experience Design?
- Usability Defined
- Building Human Centered Services
- Outputs vs. Outcomes
- Tools for Collaboration
- Upcoming Projects
- Design Prototypes
- Visual Design Library Typographical Hierarchy
- Project Planning Board
- Microsoft Teams Channel
Weeks 3–4
- Areas of Focus for High-Quality Design Standards
- What is Plain Language?
- Plain Language Benefits
- Federal and Product Plain Language Examples
- Training Video and Materials
- Tips for Accessible Writing
- Team UX Writing Guide
- Org’s Editorial Style Guide
- Org’s Diversity, Equity, and Inclusion Language Guide
- Org’s Tone of Voice Guide
- Usability Heuristics
- Psychological Heuristics
- Trauma-Informed Heuristics
- Content Creation Workflow
- Team SharePoint Site
Thank you for the warm welcome and smooth experience. I can’t wait!
Establish Team Vision, Goals, Norms, and Workflow
As part of the team’s onboarding, I created brainstorming boards for all of us to contribute to as part of shaping how we’d all work together as a team. Whenever a new team member is onboarded, they also have the opportunity to share their perspective.
As a manager, it’s important to me that everyone feels valued, important, and has opportunities to learn and grow their interests. It’s also helpful in setting expectations for how we work together. Understanding how others like to collaborate, especially in a virtual setting, is important.
Content Strategy Statement
“Plain language helps our teams communicate and build trust. By creating concise, clear content we support and respect people’s needs. During distressing times, our workforce and clients will feel relieved by our ease of use.”
Screenshot From Team Lucidspark Board
I created a board in Lucidspark for the team and I to create a content strategy statement and discuss what our group norms, values, and success indicators should be.
Screenshot From team Lucidspark Board
Another early team activity we did was brainstorm what should go in our team UX Writing Guide to supplement org editorial guides. We then worked together to write it.
Build a Team SharePoint Site
From the beginning, I anticipated the need to educate team members across departments about what plain language is and why it’s important. I wanted to be able to provide them with a source that could easily be shared with everyone. For this reason, I built a SharePoint site for the UX writing team.
The SharePoint site contained everything related to the team in one organized location. I had never built a SharePoint site before, but with my past experience as a web designer and with front end development it was straightforward. I did have to reach out to IT with questions I had about settings, though!
The team SharePoint site contains information about:
- Plain Language
- Trauma-Informed Writing
- Writing for Diversity, Equity, and Inclusion
- Accessibility in Writing
- UX Writing for Our Products
- Writing for the Brand
- Controlled Vocabulary
- About the Team
- Resources (Templates, Tools, and Learning Guides)
- Document Repository
SharePoint Site Benefits
Another benefit to having a team SharePoint is that it was made to be discoverable through search across the organization.
Over time, I started receiving messages from across the organization taking interest in plain language including members from marketing and the communications department. This was a great testament to the work that my team and I did.
Structure a Document Repository
Image Source: Freepik
New Method for Organizing Documents
Within the SharePoint site, I structured where we would keep all of the documents that the team worked on. The organization never had a method for maintaining documents before.
To keep organized I created a folder structure, naming conventions, and document statuses for each file. I was happy to learn that these capabilities are built into SharePoint. When working with large amounts of files that are a work in progress, keeping track of document statuses and approvals are important.
Mentor Team to Create UX Writing Guide
First, We Inventoried Existing Org Language Guides
Upon review, I found that the organization’s existing writing guides were geared towards printed materials and marketing rather than digital products and plain language. This highlighted the need to create a supplementary guide geared towards the work we were doing for plain language with digital services and products.
Creating Our Own UX Writing Guide
I was lucky to find that the organization’s communications department already had two official language documents. This was an excellent starting point to take an inventory of the information within them. It was also helpful to learn about writing conventions that had already been established so that we could follow them where it applied to our work.
Before we began writing content, it was important to compose the writing guide first so that everyone could start from a shared understanding. The final guide was 57 pages. The team did a great job!
The UX Writing Guide includes topics such as:
- Foundations of UX Writing
- Guidelines for Different Platforms
- Writing for Different Purposes
- Plain Language
- Organizational Considerations
- Geographical Internationalization and Localization
- Content Governance
Create Reusable Templates
To build consistency into the writing process, I created a series of reusable templates for usage by the team when creating different types of content. Depending on the content to be written, there are different considerations to account for.
Content design templates were also beneficial to our business stakeholder, translation, and development teams by:
- Building resiliency and increasing the speed of content design in the aftermath of a disaster. This meant new programs launched faster than ever before for clients to register online.
- Providing the translation team a framework to use while translating content.
- Proactively supporting developers to build all aspects of digital content such as document naming conventions, subject lines, pre-headers, alternative text tags, meta tags, and more. Previously, these elements were often overlooked.
Email Messages
Screenshot from Email Message Template
The email message template in Microsoft Word contains all content parts of an email message.
Emails are more than body copy and a subject line! The template for email messages includes everything, including pre-headers, character count guidelines, alt text, and standardized header / footer information.
SMS Text Messages
Screenshot from SMS Text Message Template
The SMS text message template in Microsoft Word containing all content parts of a text message.
Writing text messages may seem straightforward—we do it every day, right? But, exceeding 160 characters causes significant processing times when thousands of messages are sent at once. It also increases the likelihood of messages being rejected by telecom providers and people not receiving important, time-sensitive communications.
User Interface Pages
Screenshot from User Interface Page Template
The user interface content template in Microsoft Word contains all content parts of an interface screen.
Headings, body copy, meta tags, and image alt tags are less obvious but critical accessibility and design considerations when writing a user interface product page. The user interface content template makes sure these pieces of content are accounted for.
Content Brief
Screenshot from Content Brief Template
At the beginning of each project, I prepared a content brief of 2–3 pages for the team using the template I created.
Content briefs help everyone at the start of a new project, including goals and objectives, information about the reader, metrics, stakeholders, reviews, and an outline of the type of content to be worked on. My user research artifacts like personas and journey maps were also linked to build shared understanding.
Content Audit Sheet
Screenshot from Content Audit Spreadsheet
Pictured above is a screenshot of our content audit template in Microsoft Excel showing part of the spreadsheet.
I am a firm believer in first understanding what exists and why before working on a project. This is where the content audit sheet comes in.
By taking an inventory of existing content and evaluating each document through a set of criteria, we measured the current state against future edits. Then I used this information for benchmarking improvements and showing the value of the team’s work. This sheet served as a valuable tool to measure progress towards improving reading level scores.
This template was created using a starter template I discovered online and modified to meet the team’s needs.
Establish a Controlled Vocabulary
When working with complex information it’s necessary to implement a method to keep track of content variables. This is beneficial to have as a reference during the writing process for everyone on the team. It’s also helpful to people who are new to the organization that find themselves writing content.
To do this, I was inspired by Abi Covert, author of an excellent information architecture book, How to Make Sense of Any Mess. She recommends keeping track of words that are used and not used along with the history behind them.
I expanded on this idea to include usage guidelines and reusable content blocks of information. Usage guidelines outline where a block of content is used along with different contexts and nuances. Content blocks are chunks of content that can be written once and reused throughout different places as needed.
The Controlled Vocabulary and Content Blocks document contains:
- Words We Say
- Words We Don’t Say
- Content Blocks
Words We Say
Words We Say are definitions and background history about the words the organization writes across communications. There are also guidelines for how to use them in product and service design.
Words We Don’t Say
Words We Don’t Say contain specific terms, why we don’t say them, and alternatives to consider during the plain language writing process.
Content Blocks
Content Blocks are pieces of content that are reused across documents for consistency and faster writing processes. This section includes usage guidelines that explain how the block of content is used and where it should be placed in a document.
Writing Content as Part of the Design Process
User Experience Interface
One Example of Writing Content During Design
During usability testing, several users provided feedback about the complexity of the existing content (left). By incorporating plain language and trauma-informed principles, I revised the content to a grade 5 reading level and improved the user experience in my interactive prototype (right).
This Consent to Share product page is designed to capture a client’s preferences on how the organization shares their information with other partners. The original version scored at a grade 8 reading level. Many sentences were extremely hard to read. I could not imagine trying to read it in the hours after a major disaster.
Combining Usability Testing Insights and Trauma-Informed Design
During usability testing, many people mentioned to me that this page is awkward to read to clients. Some people don’t read it to them at all. This is not good because this is important information they need to know.
Plain language matters to the overall user experience. During usability testing I received this feedback about the original version of the text:
Usability Testing Feedback on the Original Version
I’m not reading all that jazz. I know we’re supposed to. I read 95% of it. I just leave out some of these and this and those. That’s about all I do. It’s just stupid. I tell my client, ‘I have to ask you this, please don’t hold it against me’…
As part of incorporating plain language, my copy revisions were reviewed by multiple users, stakeholders, and business teams. I incorporated their input before review and approval by the Office of General Counsel.
The new version that I revised scored at a grade 5 reading level. I also simplified this text to be trauma-informed by:
- Incorporating text about the importance of consent and why we ask for it. This reiterates it to responders who don’t like asking about it while building trust with clients.
- Adding text about what happens if they say “no” or change their mind later. Having choices is an important part of consent.
- Including text that clearly states that help from the organization is still available to them.
Product Taxonomy
Screenshot of Product Taxonomy Chart in Lucidspark
I created a taxonomy chart that aligns how words and their definitions are categorized for presentation to end users in a specific context. The chart was a helpful reference during the interface writing process to create a system branch for events on client cases. Pictured on the right is the information architecture for this feature in my interactive prototype.
As part of designing a new product capability to give users the ability to save work in the system, I learned there were many inconsistencies with how words were used and categorized in the existing experience. Across multiple departments staff were communicating using different words and definitions. The need to zoom in and focus on words and their definitions was apparent.
Partnering with Developers to Resolve Technical Problems
Information Architecture for Template Naming Conventions
Screenshot from Excel Spreadsheet with Naming Formula
As our development team was working on implementing the writing team’s revisions, we had an opportunity to introduce an organized information architecture in the system.
With a clean architecture, we could help end users more easily find the document they were looking for in the system. The information architecture would also benefit developers in making it easier for their team to understand which documents were being modified. This was especially important, because the current state was not organized with intention.
I met with our development team to discuss what our options were for approaching a solution. Together, we created a formula to serve as our naming convention. This formula combines the following into each template’s name:
- Functional Area
- Program Name
- Process (Job to Be Done)
- Audience
- Language
User Interface Meta Tags
Screenshot from Excel Spreadsheet with Organized Meta Tags for Product Interface
Pictured above are the first two rows of a spreadsheet I created containing product metadata for our developers.
Historically, the development team had never been supplied with metadata for product pages in the application. By taking time to write thoughtful metadata we improved accessibility for users.
Measuring Success and Delivering Value
The results achieved show an excellent improvement for client reading experience and trauma-informed design. The benefits of incorporating plain language are undeniable.
Before
- On average, the original versions of all messages was a grade 8 reading level. Several original messages were a post-graduate grade 13–15 reading level.
- Many text messages were too long, resulting in increased message size and processing times.
- Due to excessive character count length, a lot of text messages were rejected by one cellular vendor. This made them undeliverable to people who really needed information.
- Most communications were inconsistent with how information was written including tone of voice, formatting, grammar, vocabulary, and words used.
- Email messages did not have any branding applied, increasing the chance important communications were perceived as spam or a scam.
- Both email and text messages were presented as long blocks of text, making it difficult for someone to understand and take action on critical messages.
Results Achieved
- On average, the revised versions of all messages are now a grade 4 reading level.
- 62% decrease in text message segments, reducing processing times with cellular services.
- Resolved technical issue of messages rejected by cellular carriers due to unnecessary long message length.
- 63% decrease in message bit size transferred for processing.
- Simplified content into plain language makes it easier to read, accessible, and trauma-informed.
- Incorporated trauma-informed heuristics to clearly communicate choices, the information being asked, why, and what happens next.
- Improved reading experience for clients and the frontline workforce serving them after a disaster.
- Strengthened trust signals for the general public, reducing the perception of spam / scams and reaching more people eligible for programs.