What DIY Can Teach Us About Tech Comm
I recently took a few days off between jobs. To make myself useful, I decided to add shelves to the garage, a straightforward house project that wouldn’t tax my skills. I was delusionally optimistic. But I’m going to use it as a learning experience. Because otherwise I’m just looking at a couple of simple shelves that took an awful lot of time and effort to build.
Start with the right tools
I have a basic collection of tools: plenty of screwdrivers, a drill, a circular saw, a speed square. Basically, enough to get the job done, although in an amateurish fashion. This isn’t a major home remodeling job, just suspending some shelves from the ceiling of the garage. But during the course of the work I broke four drill bits and a socket wrench (I dropped it while up on a ladder; it hit the concrete and tiny parts flew away at supersonic speeds into the darkest corners of the garage).
Then I realized that using a handheld circular saw to split an eight foot long 2×4 is not only difficult, it leads to unsatisfactory results. Wobbly, uneven, and unattractive results. A table saw was the obvious answer. Since I’m not building a house, an inexpensive table saw was good enough.
The lesson? Don’t overspend on tools that have more features than you’ll use, but make sure your tools have enough functionality to handle your use cases.
In fact, don’t even look at tools until you understand your use cases. Figure out what you absolutely need and what you can do without, if necessary). Find the tools that meet your requirements, don’t change your requirements to fit the tools.
And remember that cheap drill bits are a waste of money.
Plans that seem good on the ground might not work on the ladder.
Any plan you create is only a plan. The reality of building construction methods, or of your product’s documentation requirements, quickly forces you to make adjustments.
I thought that I could use the row of screws to tell where the studs were in the ceiling. That worked for the walls, but the ceiling was built differently. The screws were drilled into a metal framework that went across the studs, and was only useful for holding up the drywall. The screws in the walls clearly marked the studs; in the ceiling, they bore no relationship whatsoever. I had to change my plans and do a lot more measuring.
Similarly, I’ve never had a documentation plan that didn’t need to change as the project progressed. If your plans aren’t flexible, they’ll be discarded. Maybe not by you, but by everyone else who just wants to get things done.
More importantly, the size of the shelves (and their supports) was constrained by factors beyond my control. I was building them to hang over the garage door because that’s unused space. But it’s also a limited space, and it wouldn’t be good to build shelves that blocked the door. And by “wouldn’t be good” I mean “could involve expensive repairs.”
Now, I knew what my customers wanted (I wanted more shelf space), and I made sure that my customer understood the limitations (the shelves are inaccessible when the garage door is open, you need a stepladder to get to them, and the shelves can’t be very big). Fortunately, a little user research found that these limitations were acceptable, and the benefits outweighed the costs.
Measure twice, drill once. Then drill again because you still screwed up.
Remember that I had to do a lot more measuring? I thought I had everything figured out, but I was making a lot of assumptions. I assumed I knew where the studs where, which would provide the structural support I needed for the shelves.
When you create a plan in a conference room (or in your living room while half-watching something on TV), it’s easy to make assumptions, because they let you make a quick decision and then move on to other decisions (or the next episode of whatever). Sometimes you can go with your instinct, and other times this leads you to drill holes all over the ceiling, cursing while drywall dust falls on your head.
Even if your plan is brilliant, it has to stand up to reality. For me, this was a garage built in a way that I wasn’t expecting. So I had to do some research: I went into the attic over the garage, looked at the studs, measured the distances between them, and then went back down the ladder to start marking where the studs should be.
Don’t assume you know everything about your market. Sometimes you need to understand how your garage structure is aligned, or how your customers do business. When you understand their business, you can understand how they’ll be using your product, and what questions the documentation needs to answer.
Don’t rush through planning, and don’t plan when you’re exhausted.
While taking a break to admire the second shelf after it was half-built, I realized that I could have anchored the ceiling beam into two more studs if I had just extended it by a foot. It’s not critical, but it would have made it more secure (probably much more than needed, but I prefer to overbuild things that would otherwise drop things on my head if they fail). I added more drywall anchors to make me feel better, but a little more patience when planning would have saved me effort later. But I was tired, hot, and I assumed that getting it right with the first shelf meant that the second one would be easier.
Sometimes you need to go with the best plan you have available. But it’s important to know when the schedule is flexible, and then take advantage of that by spending more time on planning and research. This will save you a lot of time fixing mistakes (and even more drywall in your hair) later in the project.
What did your customers want in the first place?
I thought I had put enough effort into planning, but I learned that I needed to spend more time understanding what I was trying to build and how I was going to do it. I built the shelves, and so far they’re holding together just fine. But I could have saved a few hours of work if I had spent a little more time planning before I picked up a tool.
This sounds like a few documentation projects I’ve been involved in.
Before you start working, understand what your customers need. This applies to the product and the documentation that supports the product. Understand the content that you will be creating and why. Do your customers need a UI reference, or are they really hoping for tutorials and examples?
It’s tempting to get to the fun part (writing the docs), but that part is much less fun when you’re rewriting the documentation because you started with the wrong assumptions. If you deliver half-planned, misaligned documentation, your users won’t be happy, customer support won’t be happy, and you’ll have a lot of sawdust … err I meant blame … on your head while you go back and fix everything. And that much drywall dust is itchy and hard to clean up.
