Building the Content of a Design Doc

At the conclusion of each design sprint, you and your team will construct a public-facing document that presents your process and outcome. You will be assessed using the Design Rubric (or a variation of it). This will consist of:

  1. A post on Medium. With your permission, I am hoping to republish the 2 or 3 consensus favorite outcomes of each assignment and make them public on the course homepage.
  2. Embedded in your post, a demo video that shows interaction with your techonology, highlighting the key design decisions that you made. This will likely require you uploading your video to a public service (e.g., YouTube). Note: some of your assingments may NOT require a video. Read the instructions carefully.

The design pipeline, from needfinding in the design space, to contextual inquirey and task analysis, to sketching and ideating, to prototyping and user studies, to evaluating, to the final product. Image courtesy of Emily Wall (Emory).

Why do I have to do this?

Motivation courtesy of Evan Peck: In May 2017, I sat down with a design researcher from Google to talk about what they look for in job applicants. She was frustrated with the applications being sent their way - “I just see images of the final product! I don’t have any understanding of the process they used to get there. What did they do?”

Introducing new technology at the scale of Google (millions of people) is a risky proposition. Small misconceptions can go wrong very quickly. In that environment, it is critical to not only create a good product, but be able to articulate the decisions you made along the way.

This requirement is to make my Google friends happy - you will be creating public-facing design documents that accompany each of your design sprints. If you do it well, these documents are invaluable to future employees to understand the kind of employee that they will potentially hire. More importantly, it forces you to justify your own decisions within the context of people - not just program functionality.

What should be in my design reflection?

Start with a one-paragraph summary. This should highlight what your design objectives were and what you created. If someone refuses to read a word of your post beyond this first paragraph, they should still have the gist of what you tried to create.

The majority of your post should clearly walk through and reflect on the design stages that you went through to arrive at the final prototype. At each stage, include some form of evidence - a video/photo of you testing your app with users, photos of the sketches you made to brainstorm your app context, a gif of some interaction you were testing out… anything!

By the conclusion of your post, you should have broadly addressed the following questions:

These kind of questions are frequently cited as the critical pieces that companies want to see. In some assignments, I will explicitly ask you to focus on one step of the design process. In that case, you should shift the focus accordingly.

For a more concrete example, this can serve as an target for what you should shoot for (although it is longer than what you need): Designing Facebook Collage.

You should have a conclusion paragraph. This wraps up and summarizes your post.

What does a good post consist of?

Writing a good post for a broad audience is not the same as writing a reflection or paper for a class at Davidson. Carefully reflect on the content, language, and visual design of your post.

Visually, what does a good post look like? Visit some blogs and scroll through the posts without even reading the content. Despite a lack of content, you are already making judgments about whether this wall of text is worth reading. How are you making these judgments? What is it based on?

Some examples of blog posts that I believe do a nice job discussing the design process:

In each of the previous posts, consider how there is never a long block of text. They are transformed into shorter, punchier paragraphs. Also notices how you never see a long string of paragraphs back-to-back. They are always broken up by subheadings, lists, or images to help readers visually parse through the information. Your posts should do the same. There is no reason why your work shouldn’t look as professional in presentation as the ones above.

All of that is to say: your post should be skimmable. For my sake, for recruiters’ sake, for the sake of best practices in writing for the masses – that means you will want to have clear sectioning to outline your design process. What those headers are depends on how you want to tell the story of your design. You may also want to sparingly consider other ways of drawing attention to critical points in your design process such as bold or italic formatting for critical points. Careful not to overdo it though – too much and it will lose its efficacy in drawing attention to the things that matter (if everything appears important, then nothing appears important).

Tips for the process: Document, document, document! Take pictures, record audio, and make videos every step of the way. Make a record of everything from early ideas all the way to final prototypes. These will be critical for writing your design documents. Note that many of these assignments (from a technical perspective) could be tackled individually. Part of the reason that I am forming teams is to increase the number of perspectives each group has to spend on reflections like this.

While the post should be a group initiative, it is useful to identify someone in your team to document your design process ALONG THE WAY and begin writing the framework of your post. The important bit here is that you are considering your reflection through the entire design process, not just at the end.

Demo Video

The interactions that you build will break over time, but demo videos last forever. In that spirit, somewhere in your design post, you should have a demo video that that demonstrates the core interactions of your interface. By the end of the video, it should be clear what the primary functions of your app are. In most cases, these videos should last no more than 1 minute.

What makes a good video?

Good videos have good visuals and good sound. The advice is obvious, but inevitably there will be submissions every year with blurry input and the soundscape of a wind tunnel. We are trying to avoid this.

Decide whether you want to use music, captions, narrative, or some kind of combination of them. Don’t create a silent demo video. Below, you’ll find some nice resources for music that you can include as a backdrop to your product.

Good Examples:

Somewhere in your design post, a demo video should be embedded that shows interaction with your final project. You will likely need to upload your demo video to YouTube or Vimeo.

Multimedia for your videos

Since our intention is to be able to broadly share these videos, it is important that we take into account copyright considerations. Fortunately, Davidson’s Library has prepared guides that link to resources that should provide you with a vast library of sound, video, and images to accompany your videos and make them look as professional as possible.

Recording your videos

Your video should be as high quality as possible. For many of your screen-based products, you’ll want some kind of screen-capturing software.

Video editors

You’ll also need a decent video editor to put together sight and sound.

How will I be assessed?

You will be assessed in 3 different ways:

  1. Most significantly, you will be assessed by me using the design document rubric. Please read through this carefully! Note that functionality is actually a small portion of your grade. Documentation and reflection of your design process is weighted heavily. You will receive feedback either through a variant of this rubric linked in Moodle, or we will discuss it in-person with your group during class.

  2. Peer feedback: In addition, a large part of your grade (typically 15-25%) will depend on peer feedback. That means if you let your team down and don’t contribute your part, your grade will be affected.
  3. Finally, during the in-class demos, you will share feedback on the demos that the other groups present using the I Like, I Wish, What If framework. I will note who participates during class.