Goal-Directed Design: Process Page

last update: March 2024

Included on this page are instructions for what should go into a Goal-Directed-Design-based Process Page. If you have questions, please contact Prof. Lahey via Teams or email.

Goal?

Executive Summary

This section acts as a summary of your entire page and is something you should strongly consider. What are the important things someone might want to know at a glance? This is an important section for job recruiters and the early stages of the interview process. Keep it short so that it exists totally (or mostly) over the scrolling break. (Also, consider steering away from templates with huge hero-style image sections at top because it pushes your content down too far.) You should consider all the information below in some similar order:

Approach. GDD (you'll elaborate below)

App idea. Distill it down to a sentence.

Objectives. What did you set out to achieve?

Role. What was your specific role?

Team size. How many?

Duration. How long did you work on this project?

Tools. What tools did you use to complete this project?

Links. Include links to all important files and/or other relevant information.

Introduction

In this section, you should lay out what the reader will experience in more detail. In short, you are elaborating on the Executive Summary. Consider:

  • Name and explain your prototype.
  • Storytelling is impactful. Consider starting with a short story about something related to your product domain. This story also serves the purpose of explaining the reason why you wanted to build this prototype.
  • Briefly describe your method (GDD) and be clear that this was a class project. This helps set expectations for the reader.
  • You should consider including the names/images of the team, including Portfolio links.
  • Explain how the rest of the page is set up, i.e., signpost.
An image of a dog walking app.

Method

In this section, you'll explain your method, GDD. Remember to explain it to someone that might have no experience with it but keep it as short as possible.

  • Introduce GDD. What is it? Where does it come from? What is the goal of GDD?
  • If you use any jargon (and you probably will), briefly define GDD-related jargon in your own words.

Research Phase

In this section, you'll explain how your team navigated the GDD Research Phase.

  • The introduction to this phase (and all other phases and sub-phases) should consider doing this:
  • 4-part model: What did you do? Why was it necessary to do it? How did you do it (i.e., the actual process)? What did you produce?
  • Include visual evidence here: images from your user research interview sessions (essential), competitive audit information. That said, it might be best to keep most FigJam stuff on FigJam but to link to the file above.
  • Kickoff Meeting. Explain how you didn't have this type of meeting and, instead, filled out a Kickoff Meeting worksheet. Explain how this worksheet helped you think from a stakeholder's perspective.
  • Literature Review.  Provide key examples from your research and especially what it taught you.
A man looking at schematics.
Two people speaking in front of a white board.
  • Competitive Audit. What did doing this help your team understand?
  • Stakeholder (& SME Interviews). Explain how you didn't have this meeting and filled out a Kickoff Meeting worksheet instead. Explain how this worksheet helped you think from a stakeholder's perspective. (If you did interview SMEs, break that information into its own sub-phase.)
  • User Interviews. What did interviews help your team understand? This is an important section and you should go into some detail here. The goal here is to focus more on process -- explain how you did the research, how you analyzed it, etc.
  • Create an effective transition to the Modeling Phase.

Modeling Phase

In this section, you'll explain how to synthesized your research into persona(s). Put another way, you will explain the results of the Research Phase and how your persona(s) came to be. Follow the 4-part model.

  • It's not enough to just show your persona(s); explain how they came to be.
  • Briefly explain what a persona is (including a definition of the term in your own words).
  • Explain why the persona is important and how it helps you synthesize all of your research into something that allows the design team to move forward.
  • You should include all the personas you created, explaining the difference between your primary persona and others. [See Pete Larson, a Primary Persona example from former students (Spring '20)]
  • You should explain how the work happened during your persona-writing meeting(s).
  • You are encouraged to at least link to visual evidence that “shows" how you created the persona(s) on FigJam.

Requirements Phase

In this section, you'll explain how your team created a list of requirements for your app. Put another way: How did you turn your persona(s) into a list of actionable items for shifting from research to wire framing? Follow the 4-part model.

  • You do not necessarily need to show your Context Scenario or your Requirements List, but you must give the reader context to this Phase.
  • How did you transition from the Modeling to the Requirements Phase?
  • What is a Context Scenario? Why is it important for GDD?
  • What is a Requirements list? How is it formed? And why is it important for GDD?

Frameworks Phase

In this section, you'll explain how your team created a low-fidelity wireframe (Key Path + Validation Scenarios) and how you transitioned to prototyping a high-fidelity version of your app. Put another way: How did you turn requirements into a wireframe? Follow the 4-part model.

  • It's not enough to just show your wireframes or images of your final prototype here; you must give the reader context to this phase.
  • How did you transition from the Requirements Phase to the Frameworks Phase?
  • Why are you wireframing? Why is it important to GDD? How does it help you get from Requirements to prototyping? Explain briefly.
An image of wireframes.
An image of someone writing on a whiteboard.
  • You should explain how the wireframe process worked for your team. What are Key Path and Validation Scenarios?
  • You should consider an image of your wireframing here.
  • You should also explain and show the transition to working on your prototype in Figma. Show particular flows (still images or GIFs)within the app to give visual context to what you accomplished.

Refinement Phase

In this section, you'll explain how your team refined your prototype via usability testing. Put another way: What did you learn from usability testing and how did you integrate it into your prototyping? Follow the 4-part model.

  • You should include an analysis of your usability testing here. Why did you do it? What value did it have?
  • You might include images of your usability testing sessions as well as images of how your prototype changed.

Conclusion

The most important thing to do in the Conclusion is to discuss lessons you learned from the process. (This is important for internship and job interviews.) What would you have done differently if given another chance or more time? Did you have any issues during the Phases? Did you have to change anything because of user feedback? Employers understand that not everything works out perfectly; how you deal with adversity and how you can reflect on past projects shows your ability to grow.