Lightswitch: An open, connected space to help students better document their work across platforms and projects

Designed by Eunsol Byun, Kevin DeLand, and Tom Garncarz
Learning Media Design, Fall 2016
Carnegie Mellon University.


Lightswitch is a system designed in a one-semester class at Carnegie Mellon University meant to help students at TechShop better document their process when engaging in making. The system is primarily operated using an RFID-tagged card called Lightswitch, which is distributed to all students. With their Lightswitch, students are able to activate three different components of the system, each of which allows them to document a different part of their process.

An overview of the Lightswitch system.

Nightlight facilitates automatic digital documentation through screencapturing, while Stagelight and Lantern allow for documentation of students’ process in the physical world by providing automated cameras to capture student work. All documentation created by these individual pieces is then passed through an online storage system (e.g., Dropbox) to Prism, a curation interface that allows students to create timelapse videos of their work.

Lightswitch was pitched as an end-of-semester project for the Carnegie Mellon University Learning Media Design course. To view the presentation in full, you can visit the following link: Pitch Slides.

The following documentation will walk through the process behind researching and designing the Lightswitch system.


Problem Statement

Prompted by MakerEd’s Open Portfolio Challenge, which seeks to expand the definition of what portfolios can be in the face of their increasing relevance in admissions decisions for higher-education institutes and professional opportunities. More and more students are making use of portfolios as a compilation of their work, a reflection of their personality, and a self-evaluative tool.

However, because of the increasingly varied technological contexts in which these portfolios are being created — students must contend with different services for hosting, storage, and creation of portfolios and artifacts — there is an increasing need to design a portfolio creation or curation system that is “open.” In this context, “open” means that these systems permit students the ability to not only document and curate the work that they do, but that this evidence of their learning and abilities can follow them throughout their educational and professional careers.

MakerEd’s challenge also entails targeting such a design intervention at students from ages 13–18. These students are often the ones who most significantly need strong documentation practices to showcase their work for college admission decisions, but also are most strongly impacted by artificial institutional and technological barriers between them and their documentation. Artifacts of work done in previous classes or years of class are often lost to proprietary or ineffective systems, and as such, often the only remaining evidence of the student’s work is the project itself.

Additionally, students in this age range are often less experienced in creating portfolios or other documentation artifacts. Although project-based learning is becoming more prevalent in certain specific educational contexts (Barron & Darling-Hammond 2008), much of the classwork that students engage in prior to this point in their educational careers is based more on evaluation than creation. As such, our system needs to not only facilitate documentation practices, but also scaffold them in a way that helps students learn how to assemble meaningful portfolios.

From this problem statement, we surmise our system must be able to facilitate the creation of documentation in a way that allows students to maintain functional ownership over their work, as well as make the process easier for them in a time where this kind of high-level self-evaluation can be difficult. With all these points in mind, we propose the following statement of our vision for such a system.

Vision Statement

We want to explore the design context of helping students effortlessly document using existing informal mediums as a way to scaffold documentation practices, especially in spaces such as TechShop. In this sense, “students” pertains to MakerEd’s demographic of students from ages 13 to 18, while “effortlessly” indicates that we wish for our system to promote a documentation service that is seamless and even fun to use. One of our biggest goals is to ensure that the technological barriers and transitional hang-ups that hurt other documentation services don’t plague our own. Finally, “existing informal mediums” means that we aim to use currently-existing technology and services to structure our service. These sorts of technologies include storage services like Dropbox, as well as TechShop’s existing student ID badging practices. In taking advantage of these services, we are able to create a cost-efficient and open documentation service that is able to preserve TechShop’s own culture and technology.

With this system, we hope to help students better understand not only how good documentation is created and curated, but also the conceptual and educational benefit of said documentation. We hope to help students create their own narratives around their projects with this system, and, in doing so, get them to think differently about how and why they create what they do.


Design Research and Synthesis

Guiding Literature

User research is critical foundation on which your designs are built.
- Cooper et al (2014).

Before we dove directly into design research, we planned what research methods we should use to learn about the users and get valuable insights from the process. We first started by creating a stakeholder map to analyze relevant stakeholder to portfolio practice. The stakeholder map helped us identifying which group of stakeholders to conduct user research with.

Our map of the stakeholder ecosystem surrounding student portfolio practices.

User Studies

As a way to begin our research process, we decided to interview users from four separate user groups. These groups were chosen based on the ecosystem map above, and were meant to give us a better top-down understanding of the culture space surrounding making and portfolios, with respect to our goals. These groups are educators, university students, TechShop employees, and TechShop students. These groups were chosen in order to explore the full range of potential groups of interest within our design space, so that we might learn as much as possible about our users and that this learning might influence our designs. When taken as a whole, these user groups represent the educational space that we hope to design for, as well as the different demographics that we hope to engage with our design solution. In order to better understand these users, we asked them about the work that they do, their documentation practices, and the value they saw in an open portfolio.

User Group 1: Educators

We interviewed Nina, director of Assemble, and Megan, director of Instructional & Innovative Leadership at Fox Chapel School District.

Both interviewees emphasized the positive impacts of project-based learning on students, as well as their desire to help students document their process of growth through these projects. They also suggested the need for a common system to help students communicate their process through portfolios and to take those portfolios with them through their educational careers.

Nina and Megan’s User Insight boards; we created these to better understand the individual users we consulted. Breaking down motivations, goals, and challenges allowed us to look at all of our interviewed users from a high level.

User Group 2: University Students

We interviewed four CMU students, Neil, Robert, Jen, and Yiran, who previously created portfolios with the intent of using them to help secure some extrinsic reward, such as a job, an internship, or a graduate school admission. As such, all were familiar with the necessity of portfolios and documentation on a professional level. Students made clear distinction between a portfolio and a more personal creative outlet, like a blog. These students felt uncomfortable sharing unpolished work or works in progress on their portfolios, as they felt these pieces were unsuited for the more “pristine” atmosphere implicit to portfolios. This distinction impacts not only the content, but also the styling and organization of the portfolio space.

A consolidated view of our CMU student interviews. This infographic shows the making and documentation processes of our interviewed students, and helped reveal the points where they differ. In this case, it’s shown that Zach often elects to leave documentation until the Publishing Phase, where it overlaps with his curation efforts.

User Group 3: TechShop Employees

The two TechShop employees, Bill and Erin, that we interviewed believed that student portfolios could be a boon not only to the students themselves, but to TechShop as an institution. While incorporating documentation as a structured process there would require a bit of subterfuge on the part of educators, they suggested that existing technologies that the students already use might be leveraged to this end.

User Group 4: TechShop Students

While the four students we spoke to all demonstrated different workflows and reasons for making, they all suggested a need for a better consolidated space to store their work. The ad hoc methods of organization seem to be insufficient for the students’ needs.

Personas

After conducting user interviews, we mapped the users into an xy-coordinate with “Theoretical Awareness of Benefits of Documentation” as the x-axis and “Existing Practices” as the y-axis. The x-axis indicates how much the user understands the importance of portfolio practices. The y-axis represents how much the user currently engages in documentation practices in their day-to-day work. When examined relative to each other, our user studies demonstrated four different categories of user per these axes.

Based on this user mapping, we created personas for each of the four groups to make sure we consider all portfolio users in our design. We also identified where our design should lead the personas and what is needed for each persona to follow that direction.

Here are our four personas: Alicia, Eric, Matthew, and Stella.

Using our users as guidelines, we were able to assign a persona to each area of our coordinate system, thus designating specific personas to specific needs and giving us a focal point for our design process.

Assigning user groups to personas allowed us to define specific types of users that our system might be able to target.

Concept Development

Early concept brainstorming for the Lightswitch system

With the insights from user research in mind, we started brainstorming design ideas. The ideas grouped around automaticity/effortless methods of capturing, giving guidance on reflections, social aspect of portfolio such as sharing with communities, giving extrinsic incentives and intrinsic rewards to the users and prompting documentation. Based on these ideas, we started creating storyboards.

Concept Prototyping & Refinements

We created 6 storyboards, combined and refined them into one complete story that we elaborated with details into an experience map.

Our experience map for students using the Lightswitch system (then referred to as TechBadge).

Prototyping Session 1

Protocol: we tested with four middle school kids at TechShop’s weekend maker lessons. The project that day was vinyl cutting. This involved three steps: finding an image to cut out of vinyl, bringing the image into Adobe Illustrator and tracing a line out of it, and then cutting out that image with the vinyl cutting machine. We gave each student two buttons and told them one button was for happy moments, and the other was for frustrating moments. When a student pressed a button, we would snap a picture of their work with our phone camera and then make a note of what they were doing.

Findings:

  • Students need to be reminded to document consistently.
  • Our design needed some automatic process, otherwise the students won’t have enough artifacts
  • Product must be capable of collecting digital artifacts in Illustrator or TinkerCAD
  • Students were hesitant to push the frustration button. Perhaps they didn’t want to acknowledge that they’re struggling?
  • One student said that the happy/sad emotion buttons made him think differently about the project (supporting metacognition!)
  • Students generally were interested in pressing happy button
  • They used it in ways we didn’t expect, i.e. Brainstorming
  • The girls used it to take pictures of possible ideas they wanted to do (i.e. different quotes to vinyl cut)
  • Noah used the “frustration” button to cap a picture of ugly shoes
  • Both of these are examples of how the buttons might be used to help them shape their own tastes and find their own characteristics

Questions:

  • How would students react to a more automated process? Is it creepy? Untrustworthy?
  • Can uneasiness be alleviated by showing a worked example ahead of time? I.e. this is what we’re going to be doing, don’t be too creeped out
  • How should we think about the joy vs. frustration dichotomy?
  • What is the balance between automaticity and control?
  • How will we build a product that will best allow them to transfer to other contexts?
  • Want to make them think about documenting and portfolios long after they have left TechShop.
  • Mobile app would be transferable

Design Implications:

  • Automatic screenshot collection when user saves (Ctrl+S)
  • Maybe an interaction that makes the frustration more explicit, i.e. a punching bag or a big red button or a stress ball, would be more engaging
  • The students need to see examples first to understand how the artifacts would turn out to be and therefore motivated

Photos:

An example of the Emotion Button prototype used with TechShop students. A “Wizard of Oz” style prototype was used to prototype the system; students hit the buttons when they felt happy or frustrated, and we took pictures of their work.
Student’s comments at points in their process when they triggered the happy or frustrated emotion buttons.

Prototyping Session 2

Protocol: we tested with Zach, one of our previous research subjects, while he designed, prototyped, and built a model of the biological model of a frog’s defense mechanism. This involved designing the model on pencil and paper, building a simple prototype with cardboard, creating the design in Illustrator, then cutting out the final product using a laser cutter. Our goals were to obtain content to compose a professional worked example, to test the effectiveness of an overhead time lapse camera, and to test our button system with an experienced maker.

Findings:

  • He would love if there was a little photo box, or something to signify where the focal plane was
  • He said he didn’t need two buttons, as he knew how to identify the moment of inflection and could classify it later
  • There may be situations that could be neither happy nor frowny, and he would like to be able to define what those are
  • “The camera raises the stakes, and is a positive influence on me”
  • He will use the timelapse video and the photos in a blog post about his progress
  • Thinks the system could be very useful for people (himself included)
  • Is doing a “make-one-thing-a-day” type project in February and is hoping he can use it again, as it would “save him an hour of documentation every day”

Design Implications:

  • More user control over emotional labeling. However, keeping it simple with only two options may be better for novices

Photos:

Zach’s work station, complete with buttons and time lapse camera.

Here is the final result of Zach’s work session:

And a link to his project documentation.

Digital Interface Prototyping Session

We performed a user test of our wireframes for the web curation interface. This helped us refine our design in two ways:

  • Making each image reflection section a pop-up over the entire window, rather than a static interface alongside that image
  • Not forcing users to write something for each image, by giving them the ability to skip.
A whiteboarding test session of the Prism UI.

Interactive Prototype (Prism UI)

With the three capturing tools, Stagelight, Lantern, and Nightlight, the students can collect a lot of artifacts along their process. However, the students still are in need of a tool that organizes the collection and curates into a comprehensive portfolio piece. Prism is the curation tool that serves the job. We designed this web-based platform to have several features including (1) the time lapse video, (2) the photos manually taken by the user pressing emoji buttons, (3) number of prearranged questions that help the students in writing reflections and annotations, (4) editing function to show or hide certain pictures taken, and (5) sharing the processed video or the platform itself with others. Like other components of Lightswitch, Prism is also connected to TechShop badge id so that it is synched with the system to gather the artifacts. We started by creating low fidelity prototypes, then moved to mid and high fidelity mockups. Interactive prototype produced by InVision can be seen from here. https://invis.io/AF9LANJNP

Reflection/Post-mortem

What went right?

Much of our early design work took inspiration from problems cited in the literature surrounding portfolio practices, including the difficulty associated with capturing pictures and other documentation artifacts while working on a project (MakeSchools 2015). Addressing these issues with automated systems situated in TechShop helped us gain a strong theoretical foundation for later revisions of the system. Additionally, a focus on tying all of our design interventions to the Lightswitch RFID badge allowed us to work within design constraints grounded in existing technology, making for both an easier prototyping experience and more feasible final designs.

What needs more work?

Defining more concrete learning goals and indicators of success for the project might have helped us gain a better understanding of the system’s efficacy after being implemented at TechShop. Given our interest in developing both students’ theoretical understanding of the benefits of documentation, as well as their practical documentation abilities, it would have been beneficial to develop more objective measures of success for both of these metrics.

On a different note, it would have been great to have the opportunity to further prototype the number of Emotion Buttons that students would have access to during their making process. Earlier prototypes had interchangeable button faces that would have permitted more granular emotional documentation, while others had only one button whose meaning would have been determined by the student in the curation phase with Prism. More time to test these variants might have resulted in a more effective design, as we never fully had the opportunity to understand the trade-offs of these different approaches.

References

Barron, B., & Darling-Hammond, L. (2008). Teaching for Meaningful Learning: A Review of Research on Inquiry-Based and Cooperative Learning. Book Excerpt. George Lucas Educational Foundation.

Cooper, A., Reimann, R., Cronin, D., Noessel, C. (2014). Understanding Users — Qualitative Research Ch. 2. In About Face: The Essentials of Interaction Design, 4th Edition. Wiley.

MakerEd Open Portfolio Research Briefs. In The Maker Ed Open Portfolio Project: A Networked Vision for Sharing and Documenting (2015) by Christian McKay, Anna Keune, & Kylie Peppler, Indiana University Stephanie Chang & Lisa Regalla, Maker Education Initiative.

MakeSchools Higher Education Alliance STATE OF MAKING REPORT (June 2015).

This work is licensed under the Creative Commons Attribution-NonCommercial 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.