2.4: Usability, Use, and Participatory Design

Usability, Use, and Participatory Design

Having looked at the writing process and the way it relates to use and users, we’re now ready to tackle a much broader topic—usability, user-centered design, and participatory design. While the writing process we’ve looked at is a fairly simple conception of the interaction between the user and the author, this section will dive into a much more hands-on approach that we can and often should use to make sure our work is going to match up with the needs of actual users. We have so much we can learn from our users: they are the world’s foremost experts on the tasks they carry out on a daily basis.

Usability as an Approach to Writing and Design

Usability is entirely oriented around use—how easy to use is a device or a system or a building or a text? Does it allow different types of use? Does it guide users to use it correctly? Is it open to users with different accessibility issues? All of this and more come into usability, though the term gets thrown around today in ways that more often than not imply a sleek design rather than a usable one.

For us, usability and user-centered design come down to putting users and use before production-oriented concerns. This isn’t always possible to the extent we’d like, but it is an ideal that we should continually strive towards. After all, our documents are supposed to be used and should be designed around that use rather than their production.

What does production-centered design look like, and how is user-centered design different? Production-centered design is a design process where we write or design a document in a way that makes things as simple as possible for us, the person doing the writing, or our organization, the group putting the writing out into the world. What is easy for you is not always easy for users. Sometimes there are legitimate production-centered issues that impact users, such as two-factor authentication that makes logging into a service much safer, but also more of a hassle. However, most production-centered issues come to placing the author before the user.

For example, you might use your own terms or disciplinary terms in a document that is meant for the general public. Production-centered design focuses on gets the text out the door with the most efficient and writer-centered choice available. Often, that choice is simply keeping complex terms. After all, if someone really wants to understand what is going on they’ll do the research. Right? Unfortunately, internal or disciplinary terms can be an insurmountable barrier to some, or may turn some readers off a text entirely. Think about water quality reports and ingredient lists on packages— if you don’t understand what the words mean, you’ve got to do a lot of digging to figure them out, and even if you figure them out, you may not know what the associated text means for you. Should I be worried about turbidity or anhydrous dextrose? Production-centered design leaves that question up to me and the Internet. That’s an awful combination.

User-centered design takes a different tack entirely. It asks what the reader needs from a text to make use of it effectively, often couching that question in actual research with users in the manner that we’ve discussed previously. While this is more work, it often results in documents that are more effective and users that are much more fond of your organization and your work. While many organizations talk about usability as part of their workflow, not very many actually go through the trouble of making their work user-centered as opposed to production-centered with some lip service to users at the tail end of the development process. You can think about user-centered design as a competitive advantage!

What does usability as an approach look like? We can visualize it with a simple comparison of the two different approaches as competing workflows:

Production-Centered Design

1. Assess purpose

2. Draft Document

3. Edit Document

4. Test Document with users (optional)

5. Revise document lightly

6. Publish

User-Centered Design

1. Assess Purpose Internally

2. Assess Purpose with users

3. Finalize purpose weighing internal and external factors

4. Draft document

5. Edit document

6. Test document with users

7. Revise document as heavily as needed

8. Publish

In the two cases, the difference is how quickly the user is consulted and how aggressive that consultation is. The two permutations above are aggressively different, though user-centered design can operate on a spectrum between highly involved and lightly involved. The main difference is that users are taken into account from the start. At the extremes of production-centered design, users are an afterthought at best. They are simply the people that make the document or system work, and the document or system’s effective circulation/operation is the most important consideration.

Now, sometimes we do have more production-oriented designs for special reasons such as security. If you are writing documents that contain highly sensitive documentation, you may have a more production-centered workflow that doesn’t let you open up your text to users as much. Why? Because things that would make the document easier for users would also comprise the security of the workflow. Sometimes we pay a price in ease of use for added security in technical writing settings. With that said, a good technical writer goes to great lengths to minimize the impact on readers in such situations.

The drafting process we sketched out earlier in this chapter you may note is closer to the production-centered design end of the spectrum than the example above because purpose is primarily seen as being an internal matter. Practically speaking, this is a concession to political realities—you often are not given enough time and space to assess purpose with your users and your organization. In an ideal world though, that is part and parcel of the design process. Note that you could easily add external users to our process from earlier and make your process instantly more user-centered.

Participatory Design

At the extreme end of the user-centered design world is what is known as participatory design— design where the user is a participant from the get-go, much like the example we just finished discussing. This kind of work is hard, but the benefits can be immense. The major difference between user-centered and participatory design is agency. Participatory design gives the user agency and control over the design process rather than simply consulting them for more data to help make decisions about the writing process.

When it comes to letting users into the process of drafting a text at the start (and giving them agency), things can get tricky matter. There are ethical concerns—users might criticize their boss and their boss might find out! There are also logistical concerns—how do you end up getting good information from folks and getting them together with designers? And, there are political and financial concerns—how do you convince your organization to let users help you think through things and spend time that could be used drafting to communicate (and possibly compensate) your readers?

With that said, participatory design can be a huge boon for your organization because your readers and users know more about what they need and want than anyone out there! Often times when users work, they work around bad workflows and bad documentation. How many times have you seen in a professional environment a situation where a document or piece of software is lightly used or misused? Think about a clinical setting where someone is putting information into a client management software system—many times huge sections of the system are skipped because they simply don’t fit the need of the office, but the software wasn’t customized to those needs so they are there anyway. How many times have you been handed a form and someone tells you, “don’t worry about that—we never use it!”? In each of these cases you have documents being misused because they don’t fit actual workflows or they impede them.

By taking what users know about how things actually work and what they actually need, you can make a better document, build a better experience for users, and make everyone happier in the process ideally. You can remove content that isn’t going to be needed, you can add content that is needed but not present, and you can build a relationship with the folks you interact.

With all of this said, participatory design isn’t a fit for every situation. In some cases, users want things that are not possible for legal reasons. In the case of real estate, the user might want to indicate the type of buyer they want for their home. That’s illegal. In other cases, the benefits just aren’t worth the cost. Participatory design is not for every situation, but for situations where your users are going to be incorporating a document heavily into the way they work and operate, it can be useful.

Doing Participatory Design

Having talked a great bit about participatory design, what does that workflow look like? An extreme commitment to participatory design can be seen below where I’ve sketched out what an example might look like where you commit from the front to back of a design process to working with users rather than for users. Again, this is not practical or even advantageous in every situation, but in the right circumstances it can be invaluable! (And, this is just one suggested workflow—it by no means represents the entirety of participatory design).

Participatory Design Workflow

1. Build relationship with users—find out what they like and dislike about documents

2. Come up with parameters for the design process—what will be the scope and timeline?

3. Arrange to work with users to brainstorm ideas on the document’s purpose

4. Come to agreement internally and externally on purpose

5. Draft a skeletal outline of the document/system

6. Consult with users for feedback and comments

7. Revise the draft/skeleton

8. Consult with users for feedback and comments

9. Complete the document as envisioned

10. Test the document with users, soliciting feedback and suggestions

11. Revise the document as heavily as possible, potentially reverting to step 4

12. Test the document again

13. Revise the document as needed

14. Publish the document

15. Consult users regularly on the document’s impact and unforeseen issues

16. Revise periodically with user’s input and consultation

As I have mentioned, the above is a heavy investment into working with users. It isn’t always the best choice, but it can literally give you information that can be found nowhere else and can help you find solutions to problems that you aren’t even aware of that impact the way your organization and those that use its documents operate.

When to use participatory design?

In an ideal world, I suppose you would use participatory design for every single major writing project. After all, folks should have a say when things are going to impact how they work and live. But, we don’t live in that ideal world and we often have to work in environments that aren’t open to participatory design. So, when should you take the time to aim or participation? The checklist below can help you think through this question:

Participatory Design Assessment

• Do my users operate with my document in ways that I don’t understand?

• Do I often see users using documents in ways different than intended?

• Are there problems between the way forms are filled out and how my organization uses them?

• Do I have a relationship with the users that I can leverage?

• Can I have users participate in an ethical and legal way?

Answering the questions above can give you an idea if you have enough benefits to start to make an argument for user-focused participatory design. If your organization doesn’t already use participatory design, you may have to start with baby steps, working your way towards this process with some user-centered choices. In all such situations, be on the lookout for ways that you show the benefits of getting outside feedback—you need to be able to explain how working with users benefits the bottom line.

What might things look like if your organization and your users are going to benefit from participatory design? One example might be the process of buying real estate. Buying a home or other type of property is often a dizzying task for many first-time buyers. You have to consult a bank, you have to find a realtor to work with, you have to tour properties, understand loan options, make bids and assessments of value, navigate inspections—all kinds of peril await! But, what if the process was full of documents that were designed in participatory ways?

In such a scenario, a real estate group would consult with the types of first-time and recurring clients they operate with. They would ask the clients what types of things they do well, and what types of things they don’ t do so well. They might focus on things like client education. When a real estate relationship starts, how much information is shared with the client? Perhaps a client is going to be buying a rural property that is eligible for federal grants for rural development. What does the client want to know? How would they use that information to assess things? Those are questions that only the real estate group could answer by workshopping with clients about what is valuable and not-sovaluable.

With recurring clients, maybe more of the information revolves around getting loans and paying taxes when you are buying multiple properties, operating as an LLC or other legal construct, or operating across state lines. In those situations, the same type of workshopping with clients could be advantageous. You can identify what they need, what they ignore in current information, and the times and places they simply need questions answered that you either aren’t answering or aren’t being asked in the first place.

The outcome of these workshops would likely be a draft of some informational documents for the clients, documents which could be tested with clients as they navigate the process, and documents that could be assessed at the end of real estate deals for suggestions to tweak them on an ongoing basis.

The end result of all of this would be a series of real estate documents and a workflow for clients that would likely go above and beyond what is found with other real estate groups. Yes, there would be a cost, but the benefits would be immense with clients having a firmer understanding of their options and a greater connection with the real estate group and appreciation for their efforts to make the process as demystified and clear as possible.

Section Break - Usability and Users

1. Where do you see usability referenced in your daily life? How is it used? Do you think these representations reflect on what we’ve discussed? Why or why not?
2. Think about your own institution: what systems on campus could benefit from a user-centered or participatory design approach? Why do you think this would be beneficial? How would you argue for this change with the upper administration in terms that they would appreciate?