Documenting change

An exploration into maintaining change in deliverables

One area I’m still working on, especially when building a product from scratch, is getting all the details covered.

In the past, when I’ve designed things that I know I will be building, all the small things I’ve missed explicitly writing out in the discovery/UX phase is fine because it’s in my head. I don’t worry about keeping prior artifacts I may have developed up to date because I have it all in my head.

That doesn’t work when someone else is developing what you have designed.

Here, our process (which is still a work in progress) has been:
 Prototype > High fidelity > Develop

For the most part, I have been lucky to be in house with my developers, and when things come up, and they will come up, we talk about it. Shoutout and many thanks to my husband and Nathan for being patient and collaborating — I know it’s all too tempting to make a decision and forge on.

However, we have run into a few issues where something came up we’ve decided on changing it, went to sleep, forgot, wasn’t sure if it was the prototype or the high-fidelity mocks that had been updated, etc.

Requirements:

  • Must be one place to look — not several
  • Must convey both the functionality and the visuals of the update

Options I’ve thought about:

  • Keep a running change log document (but would anyone really refer to a Word document or a spreadsheet?
  • Be more diligent about updating the prototype and the high fidelity (more work for me, but easier on the developers)
  • Start using Adobe XD, and since we have a style guide, build the prototypes in high fidelity — one deliverable, keep that updated.

So how do you keep things updated once development begins? Is this a problem you run into? How have you solved it?

Ashley Crutcher is a UX Designer at InterVarsity located in Madison, WI. She tweets at @ashleyspixels and enjoys cuddling with her cat, crocheting, working out, and thinking too much about everything.