Documentation becomes sketchy
Great talks are the ones showing me a big personal problem I didn't realize I had. The best ones help me solve these problems.
Chalk up "Communication through the use of comics" in the best talks category. If you ever have the chance to see Kevin Cheng, interaction designer at Yahoo, give this talk, definitely go.
My career of writing, writing, and more writing
My life is all about documentation. In any given day, I'm facilitating meetings drilling on project scope (with a scope document written afterward), getting everyone up to speed on what I'm doing and what they should be doing (with the subsequent status mail), writing use cases (on a wiki), defining functional specifications for features (again, a wiki document), communicating what's going on in my head to others (this blog), while writing email after email about all kinds of crap. When I first tried to explain my job to my parents, I used the accurate albeit pithy explanation: "a lot of e-mail".
Information overload
It's impossible to read and digest the amount of text I churn out. But I can't stop writing documentation; it's a necessary and important part of my job. Eventually, every piece of documentation I write is useful to someone at sometime. It may be immediate, in the case of a spec point regarding how our geography disambiguation feature should work. It may be in the future, when the company tries to figure out the reasoning behind some decisions I made with a feature. Or it may be in the way future, to understand the baseline usability of our product and how far we have come. With so much documentation comes so many problems.
I've always have had issues with stakeholders reading the deluge of documentation I produce. Most of it they can skip (for now), but some of it is very important at this moment and quite pertinent to their jobs. Unless I go out of my way to make sure these stakeholders read the nuggets of wisdom, they won't expend the effort. I've come up with innovative tricks to overcome this in the past. For example, find the hidden misplaced sentence in the spec for a prize. But these tricks suggest there's a fundamental problem with the documentation, not the people reading it.
I've come to realize my documentation is unusable. Everything the business owner, developer, tester, manager, designer, sales person, account manager, and business developer need to know about a certain project is in my documentation and if they just sat down and read it all, we would all be fine. My initial reaction is to say, "It's their job to read it." That, however, is totally unfair. Until I read every piece of documentation these folks churn out, I refuse to say that. Or, there's "I can't make this any easier to understand." I don't think I could simplify my functional specifications any further without sacrificing quality. It's worse in the long run to have the highly readable but not-at-all actionable spec:
"Make it usable and pretty. Oh, and increase our conversions by 20%."
The solution?
It should also be noted, at the end of the day, I'm a user experience designer. It's my job to make things usable, fun, easy, accessible, and full of character. If I can't spend time trying making my internal deliverables to embody these characteristics, there's no hope for me as a UX designer, period.
I'm far from advocating throwing away all my documentation for some cute cartoons. But, as a scoping exercise and a high level view of the software's desired behaviors, cartoons is a universally understood tool that engages people and helps them to better understand the nuances to look for in the functional specification. Why wouldn't you do it?
Because you can't draw? Pssht. Not having a talent never stopped me from trying something new. I'll let you know how it goes.
Kevin's deck is located here. You should really go see him talk about this stuff instead. Really.
Comments