2 minute read

Collecting pieces

One challenge with stories seems to be the white paper syndrome, whenever there is a need to start a story, for example after a big project finishes, the details are often hazy, as what exactly the story should be focusing on. I found brag documents by Julie Evans help a lot. They are essentially a running list of small wins, where over time larger patterns, stories also emerge. It’s very simple to get started, just spend a few minutes every two weeks to list all the things that went well in a couple of bullet points.

Two other approaches to documenting:

  • Seriously, you need to start documenting your UX work. Here the idea is to write a “Career Project Diary”, a central place to document all project work. Documents are heavily templated to make documentation as fast as possible. The approach is more focused on portfolio pieces, and while the idea is to add on an ongoing basis, it focuses more on details rather than lessons learned.
  • Seriously, you need to start documenting your UX work. Proposes the “Career Management Document”, a “a comprehensive collection of your résumé and portfolio content”. Focus is more on portfolio pieces and on detailed logs of work done, written on a continuous basis.

Writing stories

When writing a story about a project I often advocate for the STAR narrative model, but found that while the overall structure is clear, it’s difficult to find the right details to make note of.

The Personal post-mortem seems a good tactic to get the details in order before forming a narrative structure. This seems to be also part of the reflection process that preceeds writing the story. This method asks questions organised into four areas:

  • Process
    • How did you frame the problem?
    • What was your process?
    • Why did you choose this approach?
    • How did you learn what you needed to know?
    • What kind of research was needed?
    • How did you integrate the data or insights?
  • Deliverables
    • Given the usual set of constraints, are you honestly happy with the quality of what was delivered?
    • Was the wireframe/prototype/mock/flow/other up to scratch?
    • Did you account for all the details?
    • Were stakeholders happy with the result?
    • Would you put it in a portfolio?
  • Behaviours
    • Were you flexible when things changed? (Because they always do!)
    • Did you listen to stakeholder concerns and acknowledge their feedback?
    • Did you truly empathize with their point of view?
    • Would they work with you again?
    • If you had concerns, could you communicate them effectively?
    • Did you pay attention, follow through, organize your work, and prioritize appropriately?
  • Feelings
    • Did you enjoy this project? Why?
    • Was it easy, neutral or difficult?
    • Was the workload too much or not enough?
    • What was the best thing about this project?
    • What was the biggest challenge?

Comments