I wonder if there’s a tech writer out there—in the software industry, anyway—who would argue that being involved in the design stages of a project is a bad thing.

This theme comes up time and again among our User Education team members. Yesterday, one of us gave a presentation to our community of practice about usable design, what makes something usable, and how tech writers can contribute. She suggested we come up with some metrics that help us demonstrate how our contribution to usable design increases user productivity and lowers cost.

As part of her illustration, she showed a chart about the more and more expensive it gets to fix a bug from the requirements stage through to the maintenance stage.

An idea came to mind, and I shared it with the team, that one of the things that we can use some hard numbers with is determining how many steps it takes to complete a task. The presenter had used an example to show how a process that she would have expected to take four steps instead took twelve. If we can analyze designs and determine how many steps it takes to complete associated tasks, we can tell the project team, “That’s going to be hard to explain. That process will take ten steps (or fourteen, or twenty). And when a user sees a procedure with that many steps, the first thought is ‘This is going to be hard,’ probably followed up with ‘I hope I do it right.’ Confidence goes into a nosedive.”

› Continue reading…

Bookmark It

Hide Sites

In our ongoing department reorganization, we technical writers are experiencing some angst as we carve out a desirable place for ourselves. However, as we’ve talked about it as a community of practice (no longer as an organized team with our own manager), I think we’re coming to an agreement that now is the time to make things happen—to strike, as Tom likes to say.

After the initial, high-level reorganization, Tom and I are in the same division, so we’ve discussed a plan for taking a more prominent place in project managers’ and interaction designers’ consciousness. This is the key for us because the PMs are the ones to include us in their project plans and budgets, and we would be working with designers to decide on user education approaches and contribute to the design itself.

Finding Tech Comm’s Place in the Family

After Tom’s blog post about our meeting with an interaction design manager, I asked him about his point of view and his readers’ reactions to the post. We discussed getting involved in projects early and contributing to user interface text. We talked more about this in our community meeting this week. Again, we’re looking to make sure that the people who make the decisions give us a rightful place at the table.

We also talked about many designers’ “holy grail” of creating products so intuitive that no documentation is needed. Tom reminded me and then the group of an important point I had forgotten. An interaction designer once said something like this to me, and I had passed it on to the team: “Saying that ‘if the interaction designer does his job right, the product doesn’t need help’ is like saying ‘if the developer does his job right, the product doesn’t need QA.’”

› Continue reading…

Bookmark It

Hide Sites

I’ve noticed that lately, I’ve been choosing something other than bold formatting for high-level headings. Sans-serif typefaces like Arial and Verdana are commonly used as headings, and when they get beyond about 14 points, they start looking a little too heavy.

The fact that the heading is in a larger font and is surrounded by white space sets it apart from body text, so bolding can be unnecessary anyway. Instead of bolding, I sometimes like to set headings apart using some additional visual cue like color (which may or may not help, depending on whether you have users that are colorblind) or a graphical indicator. An icon, vertical lines, background shading, or gradients can be part of a heading style and readily suggest to the reader that something is different about that text.

I’ve started to favor these alternatives, and I think they have added to the visual interest of the overall documents.

Bookmark It

Hide Sites

I started using rounded rectangles in some diagrams when I saw a flowchart that an interaction designer did. Later, my colleague Tom began using them in some quick reference guides, so I did the same in one guide and some release notes. I liked how they looked, but I don’t use them all the time, because there can be too much of a good thing.

It has made me wonder why rounded corners are appealing. There are plenty of sites explaining how to do rounded corners, specifically for websites and in InDesign, but not much discussion about why they have become popular.

› Continue reading…

Bookmark It

Hide Sites

This week, Cameron Moll gave a design presentation to a small group, including our team. He discussed some principles of good versus great design. One of the concepts he brought forward was problem-centered design. As I understand it, a solution-centered design says, “I’ve got this product, so how do I make it do what I want or solve my problem?” Problem-centered design involves focusing on a problem statement to help identify the objective and see the way to design a solution.

I wondered how to implement problem-centered design myself. Applied to documentation, a problem-centered approach seems given to forms like troubleshooting guides and FAQs. The user has a question or problem, so here’s the answer. Simple as that.

I made myself think about it more, though, because if I dismiss it as meaning just troubleshooting or answering questions, I miss a chance to broaden the way I look at what I do and thereby improve it.

› Continue reading…

Bookmark It

Hide Sites