Documentation

[brendin]

Hey guys,

I’m finding myself with a challenge. As some know, I’ve posted a few questions here since I’ve taken the position as Lead UX Designer at my company now. As first ux-er here, I obviously need to get A LOT of things in place and the latest challenge is documentation.

I am, like a lot of others, a bigger-picture guy. I need the bigger picture especially in times when I need to reflect on what I’ve done. Documenting a new process/feature seems like an essential step in any team. However, I’ve recently spoken to our PM/BI and his response was: “Why do you want documentation? Is it because you forget what we chat about in meetings or because you don’t attend meetings?” So according to my understanding, the guys just remember everything that’s said and act according to that and more often than not find ourselves not clear about a certain aspect of a feature or we fail to remember what was discussed.

I understand that documentation can be a drag and one does not want to drown the dev in documentation but I feel like something is missing. In most of our meetings, we chat so much and throw out ideas and the meeting is over without clear goals and actionables - despite this, most of the guys are content and they just figure stuff out along the way but I think that we are missing something big by skipping documentation.

I’ve recently discovered a document from InVision’s Blog which is focused on UX Strategy

and this feels like a MUST if a company wants to pursue UX.

So my question is: Am I being inconsiderate or too hard-headed to constantly want documentation or to AT LEAST go through this template’s steps before building features? As a SasS company, I think it’s especially important to have documentation.

Do you guys have any feedback regarding your documenting process or ways to make documentation easier?

[dougcollins]

For whatever reason, some people are just anti-documentation. Some people need it more than others. When it comes to documentation, no matter how good or important it is, you’ll never get 100% buy-in. There will always be at least one person who wants to wing it.

If I understand things correctly, you’re the first (and only) UXer at your company. The beauty of being a solo UXer is that you’re (usually) given quite a bit of latitude to do what works for you, regardless of what the rest of the business thinks.

You are the UX expert - and the only one at your company. Do what works for you.

Quite frankly, if you want documentation to make sure that you’re following a consistent practice and addressing all potential problems from a UX perspective, it doesn’t matter a fetid load of dingo’s kidneys what objections your PM/BI guy has.

If it were me, I’d create one of the sheets your referenced - which I love, by the way - as an artifact for my next refinement meeting and send it out to attendees with a note along these lines:

Hi everyone! I wanted to pass along my notes from our last meeting to the group. When I was putting together this summary, I noticed we [hadn’t defined ideal outcomes]/[didn’t discuss risk management]/[hadn’t talked about potential resources for the project]/[whatever other insight you might provide]. We’ll want to make sure that we touch on this in our next discussion on this project. If you have any questions or have anything to add, please let me know.

This works for a couple of reasons:

• It shows you were actively participating in the meeting. Hey, you were the only one taking notes - and they were good enough you felt comfortable distributing them to the group.

• It adds value by examining the process. More than likely, your group doesn’t really understand what pieces they’re missing. The chances are they’re missing these pieces consistently. By using documentation to point out areas that your team is missing, you’ll help the group as a whole and your users by ensuring that you’re considering all aspects of a project before you start work.

In my most recent article for UXMastery, How to Survive as Your Company’s Solo UXer, I talk a bit about the need to socialize the benefits of UX in your company. This is a great opportunity to do just that.

[HAWK]

Doug’s advice is solid as always. I’m just chiming in to add support.

Like you, I’m a documentation person. I go to meetings and I listen when I’m there (I actually find his suggestion that you don’t a bit insulting!) and I find that sitting down and documenting what was discussed is the best way that I reflect and digest.

I’ve also been in enough situations where people have left the organisation suddenly and all the knowledge and strategy has left with them to know that documenting ideas and processes is smart.

You were hired to do a job to the best of your ability and I don’t believe someone else should dictate how that happens, providing you deliver.