Using a work journal to create design case studies

Metadata:

Project name

Project start date

Last updated date

Completed: yes/no

Project version (is this a 1.0 project or something like 1.1 or even 2.0?)

Project status (Draft, In progress, Scrapped, Completed)

Contributors

Informed

Outline:

Project summary, in my own words

Project goals and key results, again, in my own words

Daily notes

Learnings and outcomes

What information you include in your project journals may be different. Over time you will likely learn that more (or less) information is helpful for you and your needs.

Most of the information in the project metadata section won't change. What will change often is everything under the daily notes portion.

Keeping daily notes

I have 15 minutes on my calendar for heads-down time to reflect on the day and journal what got done. I don't restrict myself from journaling during those times, but I have found that having that set time on the calendar helps me remain consistent.

During scheduled journaling time, I'll capture what I remember from meetings, points that came up during my one-on-one conversations, or any specific design artifacts or elements I'm exploring at the time.

My work journal's daily notes section of a project becomes a linear timeline of events.

You don't need to capture everything that happened for a project; you only should note what you think matters most for you, your personal development, and your learning. Including photos (like of you and your team collaborating on a whiteboard) and videos (like a few seconds of an early design prototype) can add to the story you're telling and remind you of what you were up to that day. Those artifacts also become invaluable when transforming your project journal into a presentable case study.

Turning a journal into a case study

Once you start contributing to a work journal, you will have begun creating a powerful narrative for a case study through the sheer nature of personal reflection and journaling.

The linear and personal format of a journal works well for translating into a case study because it focuses on your personal experience of the work. Your journal won't follow a stereotypical template of some romantic design process; it will follow the actual process you took through the work. It will be faithful to what you experienced as you worked on the project, making for a compelling case study.

A great case study format to extract from a journal looks something like this:

Where did the project start, and how were its goals defined? Did your manager tell you about the project, or did you kick it off with a team? Was the project hand-delivered to you as an assignment, or was it something you figured out?

What was your first interaction with the project, and how did you feel going into it? Were you intimated or excited? Eager or annoyed? Why?

What was the first thing you did? Not the first thing the team did, but what did you do once you learned about the project? Did you schedule meetings with stakeholders, look through past research, write down everything you knew about the work to come, or something else?

What was the first (or second) challenge you encountered? How did you feel? What did you do to work through the challenge with others?

How did the project typically progress? Did you need to rally the team together regularly, were regular meetings booked by a product manager for you, or did you set up consistent design critiques for the team to give you feedback? Did you do research, and if so, who scheduled it? How did all of that work feel for you?

Were there any notable challenges you faced during the project? Call these out! Was there a disagreement between you and someone else? Was there a time you dropped something or failed to meet expectations? How did you recover from those things?

Where did the project end up? What, if anything, would you have done differently?

That last question—it's worth noting—is a section all on it's own in my project journal format. Because there's typically a moment in a project where you wrap up your work to move onto a different project, and that's a great time to reflect on the experience.

In the learnings and outcomes section of a project journal, you should find more time than usual to go through the daily notes and reflect. Did the project end up where you and the team set out for it to go? Why or why not, do you think?

Did you learn anything about yourself, your process, or your skills from the project? What were they?

Wrap up both your project journal and any case studies that result from it by answering the question of previous questions, and you'll have created something that exemplifies why the project is worth sharing in the first place.

The work we do as designers matter a lot for those who use or experience what it is we build alongside others. But the work we do also matters for ourselves: our ability to be thoughtful and aware individuals who are constantly evolving, much like our work.

It's easy to get wrapped up in the metrics and postmortems we have for projects and forget that we are also growing. A project or work journal can help remind you of the ways you are growing and give you a great set of fieldnotes to pull from when it comes time to talk about that work in the future.