Overall goal: make a thoughtfully designed prototype that serves a particular older person’s particular need, get feedback from that person, and iterate on it. Document process along the way, and document the final product as well.

General structure:

  1. Meetings with older people in their home/community/elsewhere (week of March 26th)
  2. Documentation of this meeting (due at noon on Sunday, April 1st)
  3. Quick development and presentation of a “behaves-like” prototype (April 2nd–10th)
  4. Presentation and crit of these prototypes with older friends (April 11th)
  5. Documentation of prototyping process and feedback (due at beginning of class on Wednesday, April 18th)
  6. Elaboration/improvement/changes/finalization of the final project artifact (April 12th–May 1st)
  7. Final presentations and crits with older friends (May 2nd)
  8. Final documentation (due 10 p.m. Friday, May 11th)

Last and least: the grading scheme for this project.

1. Structuring your initial research/design meeting

The week of March 26th, each group will arrange for their own meeting with their assigned older person. The major purpose of this meeting is to gather sufficient information about that person’s life to be able to identify a need they have that can be fulfilled with a technological solution.

Because we want to give as much flexibility as possible to the older people who are generously giving us their time, we’re not requiring them to meet in any particular space. Some of them may want to meet in their homes (which is great—see below), while others may want to meet in a public space such as the JCC or perhaps even on our campus. The setting of the meeting is important and will dictate to some extent how you should plan to structure the meeting.

A suggested agenda that you may want to follow is here:

  • Introduction/icebreaker
    • Introduce yourselves by name, sharing something that reflects a personal value, interest, or other bit of relevant data about your life which will help establish a personal connection. Possibility: share an anecdote about building the assistive device for yourself (Project 2). Or: how long have you been in Pittsburgh, and what do you like about living here? Etc.
    • Ask your older friend to participate in turn, sharing their name, their interest in participating in this group activity, and prompt them with the same question(s) that you all answered to begin.
    • Ask the older friend why they volunteered for this project as well, perhaps. What drew them to want to participate?
  • Explanation and clarification about project goals
    • You want to be sure to be on the same page about this project. Explain in clear terms what it is we’re trying to do, and what we’re not trying to do.
    • We are:
      • Trying to build prototype useful devices
      • Engaging in an iterative design process, including gathering formative feedback around the midpoint of the process
      • Taking about six weeks to go from this meeting to a reasonably high-fidelity final product
      • Documenting our process
      • Capable of building sophisticated devices
    • We are not:
      • Professional technologists who are experienced in making polished products
      • Planning to build something that will be sold commercially
      • Constrained by any practicality outside of usefulness to the person we’re designing for
      • Likely to invent a totally novel piece of electronics (we combine many existing available components in new ways, but don’t for the most part make components)
    • Give a quick timeline overview of the process
    • Provide some examples to help flesh out the sorts of things that are in our technical wheelhouse
      • Bring a laptop and show some projects (your own projects are great to talk about!) from the course website
      • And, if it makes sense, bring a project or three to show what you’ve made
      • Remember that without examples, it is difficult to explain what electronic prototyping really is and looks like in our context
    • Be sure to solicit questions: ask “do you have any questions?” or “does this make sense?”, etc., as you’re going through this section
  • Understanding needs and thinking of possible technological interventions
    • This is the meat of the meeting, but it’s also the hardest part
    • There are multiple approaches that you could take, depending on the particulars of where you’re meeting, and the willingness/active engagement of your older participant. Possibilities:
      • Ask your older person directly if they have any activities in their daily life that are difficult, frustrating, or otherwise seem like they could use an intervention. This direct question may bear some fruit, but you will probably need to do some probing and ask questions to guide the answering.
      • If you’re in their home: ask if they’d be willing to demonstrate a daily task or a series of tasks to you. They can actually do the task if it’s something simple like getting a glass of water, or they may pantomime the task. The closer to reality this action is, the more likely you are to find a particular aspect of the task that’s harder than it needs to be.
      • Have the older person try to think of something that they remember enjoying doing, which has become harder with age. Are there creative ways to make that thing easier to do now?
      • Use the simple creative act of drawing to bring out ideas: ask the older person to draw a map or cartoon of their daily life, or have them narrate the action and do the drawing yourself in a way that’s visible to the group. It could be a map (literal map, showing travels), a sequence of cartoon panels (first I do this, then I do this), or take a more abstract form.
      • Bring some craft materials (tape, tongue depressors, popsicle sticks, paper, scissors, pipe cleaners) and try to mock up a problem in a funny/silly way using these materials.
      • Suggestions added by students during class:
      • Ask ethnographic questions: “why is this important to you?”
      • Once you’ve asked some of these guiding questions, use materials (clay, building materials, etc.) to mock up solutions to the story you’re telling
      • Make sure they are a part of the process as much as possible
      • Discuss and establish some categories for “problems” to narrow and refine the conversation (think back to the sticky notes process we did during the first field trip)
      • Think of this as making a “convenience machine”, one that reduces one of the little annoyances we all have, maybe call it a “gadget”? Language is important.
    • As you’re having this part of the discussion, document it as much as possible. At least one person should be taking notes, and at least one other person should be taking occasional pictures in an unobtrusive way (certainly if the older person is demonstrating something it should be documented with photographs).
    • Share thoughts and ideas as they come up. You’re trying to be as creatively fruitful as possible in a short time!
    • Keep any artifacts generated from this meeting.
    • Regardless of your particular process, try to move towards some more concrete ideas after you’ve given the open ideation enough time. It’s best to have more than one possible idea moving out of this meeting so that you can funnel down later into narrower possibilities, instead of trying to invent new possibilities later.
  • Conclude
    • Thank your older friend for their time, make sure they have your contact information, and take any final documentation images/drawings/notes you may need to wrap up before you leave the space you’re meeting in.
    • Reiterate the overall schedule if you feel it would be necessary to clarify before leaving.

2. Documenting the initial meeting

documentation due date: noon on Sunday, April 1st

It’s important to carefully document the meeting you have with your older friend so that you are sure to get as much as possible out of the short time you’ve got together. A good meeting with poor notes taken will likely only remain in your mind for a few days, and that’s not long enough.

During your meeting, take notes and photos! If the meeting produces any artifacts other than notes (if, for instance, you make a drawing or your older friend does), then be sure to capture good documentation of these. If the artifact is a drawing, then get a high-quality photograph or a scan of it; if the artifact is a small sculptural thing like a mockup with craft materials, then take a photograph or two which shows it clearly.

If everyone is comfortable having their faces online, you may also want to take a group photo with your older person!

Each group is responsible for submitting a meeting documentation post to the student work site including at least the following elements:

  • A brief introduction: Write this with an ignorant audience member in mind, somebody who doesn’t know anything about our class project, who just found this page through a web search. You should explain the purpose of the meeting, who was present, and where and when it was held. (Stick to using first names when naming people.) Include your team name.

  • Your meeting agenda: The agenda you wrote before your meeting, illustrating how you planned for the meeting to be conducted. It may be handwritten (in which case it should be scanned and the image posted at “large” size), or electronic (in which case the full contents should be presented on the documentation page).

  • Meeting summary and major takeaways: The most important part of this documentation post. Here, you’re explaining what you learned over the course of the meeting. What design ideas were suggested? Was something raised as a good idea but turned out not to make sense upon further discussion? Do you have clarity about what you’re going to try to prototype, or you’re feeling lost? This is the section where you should integrate media from the meeting like snippets of notes, photos of acting out a particular idea or problem, photos of artifacts, etc. Write captions for images as appropriate. This section should not simply be a verbatim recital of your notes from the meeting.

  • Your thoughts after holding the meeting and discussing as a team: Use this section to present a critical reflection on the meeting. For instance: did the meeting follow your agenda or go way off the rails? Or was it difficult to get conversation started? Or did it go great? What would you want to do differently next time? Afterwards, did you realize any questions you wished you’d thought to ask? Did different members of your team have different opinions about how it went?

Technical notes about the post:

  • Use the “Authors” feature that appears below the post content pane in WordPress to assign all of your group members as authors on the post. Contact course staff if you’re having trouble with this.

  • Be sure to select a “featured image” so your post has a primary image associated with it.

  • Mark your post with the “Meeting documentation” category in WordPress.

Questions/concerns/etc.? Contact course staff before the due date!

3. Initial prototype development

April 2nd–10th is the (admittedly compressed) timeframe for the development of an initial prototype. On April 11th, from 9:30–11 a.m. at the JCC, each group will present their prototype(s); the audience will be both the older person the group built the device for, as well as the rest of the class.

To ensure that the prototype development time is spent as productively as possible, it’s important that you have clear goals for this phase of the project. Prototypes come in many flavors, and one useful breakdown of a handful of types is given in Graham Pullin’s book Design Meets Disability, p. 138:

  • “feels-like”: an ergonomic prototype for feeling in hands, etc.
  • “looks-like”: an appearance model for form, colors, materials
  • “works-like”: engineering prototype for electronics, electromechanics, etc.

All of these prototypes focus on a particular aspect of the final product’s quality—namely, feel, look, and function.

The sort of prototype that each group should focus their efforts towards building in this period falls into a fourth category: it is a “behaves-like” prototype. That is to say, it is an experience prototype. It may have tethers instead of being wireless; be built larger or smaller than the likely final size of the object; and/or have unfinished or arbitrarily chosen aesthetic qualities. The one aspect that this prototype must focus on is modeling the fundamental user interactions.

That being said, it follows naturally that if, for instance, if the size of the final design critically affects its behavior, then the “behaves-like” prototype should carefully be built at the appropriate scale. Otherwise, the behavior wouldn’t be well-modeled by the prototype! Likewise, some semblance of electronic, electromechanical, etc., function should probably be integrated as well, but only need be present to the extent that it will inform the user’s experience of the core interaction.

Why build a “behaves-like” prototype at this juncture? Because in order for the feedback from the April 11th crit session to be maximally useful, the older people who are trying out the prototypes must have the clearest possible notion of what the assistive device actually does—i.e. how it actually works.

That said, it is not unacceptable for the April 11th prototype to feel, look, or work like the envisioned final product: it is perfectly fine if it does. But the focus of the group effort in this short development period shouldn’t be on choosing the right shade of paint! Rather, it should be on building an object which will allow the intended user to explore, and respond to, the way the thing will ultimately behave when it’s complete.

Reminder: take lots of pictures as you’re going. These will be integral to your process documentation later.

Printable Gantt charts for prototype planning: letter format and tabloid format

4. Formative presentation and crit

On April 11th, 9:30–11 a.m., we will have a formative presentation and crit session at the JCC. The purpose of this is for each group to show a functioning prototype and get meaningful feedback that they can use in turning towards the final development period.

Here is the schedule for the morning:

9:30–9:35 a.m.
RZ’s brief introduction
9:35–10:35 a.m.
Each group presents their prototype to the audience for feedback, critique, and suggestions (approximately 10 total minutes per group)
10:35–11 a.m.
Each group meets individually with the older person they’re working with; guest critics wander amongst groups at will

Group presentation expectations: This is a prepared presentation to an audience, but it need not be overly formal. Each group should expect to speak for ~3–5 minutes:

a. introduce yourselves, as well as the older person you’re working with, by name
b. briefly explain what problem you were trying to solve,
c. show/explain how your prototype goes about solving it, and
d. solicit any particular questions of the audience that would help in furthering the project development.

The prototype should be demonstrated to the extent feasible, so that the audience understands how it actually works: showing is better than telling. If necessary, the group members can Wizard-of-Oz some aspect(s) of functionality.

It’s a very good idea to take notes during the Q&A part of your crit—you are, after all, soliciting advice and want to write down ideas, suggestions, and critique that will help guide your design choices.

Group meetings with older people: This is a very precious 25 minutes! Most importantly, have your older friend use your device and give them time to tell you about what they’re liking about it, what they’re not liking about it, and what they think you should change. Remember that though you built the thing and know it inside out, they are the expert here, and it’s their opinion that will drive the development you pursue in the final month of class. You may find it useful to write some prompts beforehand to guide your discussion.

5. Prototype process documentation

due at beginning of class on Wednesday, April 18th

The prototype process documentation requirement has two major components: images and reflective text. Make a post on the student work site that contains at least:

  • A brief introduction for context, explaining in general terms what this post is documenting (including a link to your prior documentation post is a good idea as well)
  • Product section
    • One to three high-quality photographs showing the complete prototype. Use the PhotoZone to capture these. Caption them as needed for the user to understand what they’re looking at.
    • A paragraph explaining, in simple terms and avoiding jargon, what the “function” of your functioning prototype is. What does it do? How does a person use it?
  • Process section
    • At least eight, and no more than fifteen, visual snippets of your prototyping taken along the way; these need not be woven into a totally linear story. Each image should be captioned to help a reader understand its significance. A few captions may be brief (e.g. “A mechanical prototype”), but most should provide more insight (e.g. “An early mechanical experiment built of popsicle sticks. It fell apart soon after this picture was taken, but we thought the overall design was good and later incorporated it into our behaves-like prototype.”) Images may be photographs, screengrabs, drawings, scans of notebook sketches, etc. Images may include team members in them but do not need to. Do not re-create the past to take a photo of it for inclusion in your documentation.
    • At least one paragraph addressing each of these prompts:
      • What were the major challenges in this prototyping process?
      • Discuss the utility, or non-utility, of the crit on April 11th for your group. What (if any) input from the crit will you be using moving forward? Be specific: “A question about blind users got us thinking about creating a more tactile interface…” rather than “Comments were mostly negative so we are going to try working on a different design.” What (if any) input will you be ignoring, and why?

WordPress notes:

  • Title the post “Team ABC Prototype Documentation”, where ABC is your team name
  • Use the “multiple authors” feature to add each of your team members as authors on the post
  • Label the post with the category “Prototype documentation”
  • Select a “featured image” for the post

A good practice is to create a shared folder in a service such as Google Drive or Box into which all the group members copy their own images; this way, everybody in the group can see all of the collected media and make informed decisions about what you may want to include in your documentation post.

7. Final presentations and crits with older friends

May 2nd, 9:30–11 a.m. in the Katz Auditorum, Robinson Building, Squirrel Hill JCC.

The format will be as follows: each group will have their own table to present on. Each table will be provided with electricity, if needed.

At the beginning of the session, groups will each very briefly introduce their projects to the whole room (perhaps 30–60 seconds per table). Following that, the session will be broken into periods ~14 minutes each, with time announced. (Each table will be “staffed” by two group members at all times, but at each rotation, those members can switch out so that students are able to visit most other tables over the course of the session.)

During each 14 minute table session:

  • the table’s participants should spend the first two or so minutes introducing their project and explaining the problem it aims to solve;
  • the next nine minutes are for discussion, questions and answers, etc.;
  • the last three minutes are for table visitors to provide brief written feedback on a form that will be collected at the end.

8. Final documentation

The final documentation for your pieces will be the longest-lasting, most portable, and most accessible evidence of the work you did. The final artifact itself will be given to the person that it was designed for—it may live in their home or in their traveling bag, but wherever it is, it won’t be in your hand. You should spend time proofreading and double-checking your final documentation, and be careful to produce something you’ll be proud to point to for years to come when people ask what sorts of interesting projects you’ve completed in your time at Carnegie Mellon.

Documentation for this project is due on Friday, May 11th, at 10 p.m. It is worth 20 points out of the 60 of this project.

If you have any questions about the submissions requirements, or run into technical problems, be sure to contact the instructor or TA before the due date.

Your documentation is submitted in the form of a post on the course WordPress site. In order from top to bottom, the documentation post should include:

1. Title in the format: “Project Name by Group Name: final documentation” (1 pt.)

  • Underneath the title, a paragraph: introduce your project in the context of this class to the uninitiated reader. Provide a very brief overview, and also include in the text links to your prior posts so the reader knows they can look to those for more context and process information.

2. What we built (5 pts.)

  • Begin with a one-paragraph description, in plain and spare language, of what your project does. Avoid technical terms.

  • Carefully- and well-shot images of the final project. Take these using IDeATe’s PhotoZone backdrop and lighting for an especially easy professional look, or shoot out in the field if you prefer. The DSLR photography guide provides a lot of pointers.
    At least seven images:

    1. Overall photo for proportion and scale (possibly the “featured image” you’ll use, though not necessarily).
    2. At least three: detail photos of any part that you’d like to highlight. These could be button layouts, screen displays showing text, other design choices, etc. The IDeATe cameras available for borrowing are able to focus quite close, so with a steady hand (and/or a Magic Arm or tripod) you should be able to get good, clear close-ups.
    3. At least three: images showing the use of the thing (pushing a button, using a menu, etc.)
    4. Optional but recommended—embed one or more .gif or .gifv or short .mov (do not merely link to an outside hosting service). A brief (~5 second, for instance) movie can really help illustrate features which move or change.

Each image should be captioned. (To add captions in WordPress: click on an image, click on the pencil icon to edit it, write a caption, and click “update.”) The captions serve to explain both what the viewer is looking at, as well as elucidating some of the operating details of the object.

  • A narrative sketch of the intended use—a “story” of sorts to illustrate your idealized vision of what this thing would do, being used by the person for whom it was designed. Here’s a made-up example:

When Sam gets home, he’s looking for some inspiration, and goes to his bookshelf, where his Book Suggestor sits. He pushes the big button marked “What should I read?” and a display screen says “Brave New World by A. Huxley” on one line and “shelf 4R” on the next line. He walks to shelf 4R and finds the book.

Two days later, he returns to the Book Suggestor and pushes the “rate that read” button. He turns a knob, scrolling past “no thanks” to “so so” to “good read!”, and clicks the knob to select that answer. The Book Suggestor remembers that Sam enjoyed that author, and will raise Huxley’s other books’ rankings when the next suggestion time comes arouns.

3. How we got here (5 pts.)

A novice builder-of-things may assume that you 1) get an idea, 2) build it, and 3) you’re done! Your goal in this section is to disabuse them of this misconception.

Some aspects of your months-long process were mandated by this class—there is no need to dwell on these moments as you’ve already documented them in your two prior posts (your initial meeting notes and your formative crit notes).

Instead, use this section to discuss and analyze retrospectively the decisions you made, mistakes and discoveries along the way, and share any breakthrough (or breakdown!) moments you had. It is ok to recycle some narrative and/or images from prior posts, but this post should also have significant original content.

Use images (at least 8) to help tell your story. Intersperse text and include captions as you see fit. The images may be photographs of a workspace, scans of notebook pages, screengrabs, or any other visual artifact that’s useful for your story.

Discuss the ways in which your final build plan (the one you finalized on April 18th) was a useful tool that you stuck to, or if you diverged from it then what happened differently from the plan and why.

There should be at least ~500 words (and 8 pictures) in this section.

4. Conclusions and lessons learned (5 pts.)

A few paragraphs here, addressing:

  • Salient findings from the final crit, which emerged from discussion and/or written feedback. For instance: did somebody suggest a simple change that would significantly improve your project? Feel free to refer to feedback verbatim, but do not name the person who gave that particular feedback.

  • Major takeaways from the experience of working with an older person to design something built just for them. What surprised you, what would you do different next time, etc.

  • Add any concluding thoughts you have about the project.

There should be at least ~400 words in this section.

5. Technical details (4 pts.)

This section, at the bottom of the post, is here primarily so that others can use and build on your work.

Include:

  • Your code, uploaded as a WordPress attachment, and optionally also with a Github or other version control service public-facing link. Include license text at the top of your code if you wish (i.e. copyright, CC BY-SA 4.0, the MIT License, release it to the public domain, or just follow your heart). If you have written code that you wish to keep strictly proprietary for any reason, please speak with the instructor about an exception to this documentation requirement. Make sure that your final code as it appears on the public-facing post is correct and the latest version you actually used!

  • A cleanly drawn schematic, legible to a person with a reasonable preparation in electronics. This may be neatly hand-drawn or sketched in software, such as Fritzing, EAGLE, or in some flowchart application like draw.io. (Be sure to also upload a full-resolution version of this image so that a future reader isn’t left squinting at the pixelated version that appears on the post page.)

  • Any design files that would help someone else reproduce your project; these could be Illustrator, SolidWorks, Inventor, Fusion, Rhino, or any other design software you used. If you have cutfiles (.dxf typically), share these as well.

WordPress notes:

  • Use the “multiple authors” feature to add each of your team members as authors on the post
  • Label the post with the category “final documentation”
  • Select a “featured image” for the post

Uploading files quirk!

As of 5/2, WordPress will not allow you to upload files that are not images. We are working on this, so for the moment don’t worry about your inability to upload .ino, .ai, .dxf, and many other file types. We hope to have it fixed by Wednesday 5/9.

Grading scheme

The final project is worth half of the total course grade. Noting that the course sums to 120 points (not 100!), here is the breakdown of the 60 overall course points that the final project consists of, presented in chronological order of due dates:

  • 5 points: Community/home/etc. meeting documentation (due April 1st at noon)
  • 5 points: “Behaves-like” prototype crit and presentation (April 11th, 9:30–11 a.m.)
  • 5 points: “Behaves-like” prototype process documentation (due at start of class on Wednesday, April 18th)
  • 15 points: Final crit and presentation (May 2nd)
  • 20 points: Final documentation (due May 11th at 10 p.m.)