Role (Group of 5):
Background
Challenge
Use co-design as a mechanism to engage user and stakeholder concerns for an online peer feedback platform called Round3 (https://round3.io/). The product is currently under development, and has a functional, yet not fully visually-realized front-end experience. In particular, the clients have requested our attention to this area of focus: project preview and review. We are focusing on project preview and review within the site. This encompasses how students view other students’ projects, and how they provide and view feedback within the platform.
Problem
Need to identify, plan, and execute activities that can be conducted with different levels and types of stakeholders in the context of a co-design workshop. The outcomes of the planning and execution of the workshop will inform a roadmap for incremental improvement of the web app’s UX.
Constraints
- Instruct our own Co-Design Workshop with participants
Research
To better understand our target users
We identified our three targeted users, which were:
- The Reviewer (Primary User):
The reviewer is our primary user here. The reviewer will review an anonymous students work and comment, highlight, and annotate on the student’s project. Additionally, the reviewer will answer the feedback questions the instructor wants them to. - Project Creator/Student (Stakeholder):
The project creator is the student who submitted the assignment and is receiving feedback. - The Instructor (Stakeholder):
The instructor is the teacher or professor who oversees the the feedback sessions and provides the feedback questions from the reviewer to answer.
To better understand existing solutions
We looked at other tools who are doing work in the student feedback space. We looked at a peer feedback platform similar to Round3 called Peergrade. We wanted to see how its “project preview and review” interface looks, and what it may include that Round3 is missing. We set up both an instructor and student account to go through the process of how an instructor would set up a project and feedback session, and how students would submit a project and provide feedback to one another.
Insight
User Behavior
- Student anonymity
- Instructor intervention (Pre-set questions, description)
- Easy to understand call-to-action buttons
- Download assignment option
- Ability to save progress and return
Co-Design Workshop:
Activities
We came up with two activities for our co-design workshop: Affinity Diagramming and UI Building Blocks. Below are brief descriptions of our activities. Our goal was to gain insight into how to best design this interface for both instructors and students through hands-on activities.
Affinity Diagramming
One thing we wanted to know from our participants is what kind of feedback is useful for projects. In this affinity diagramming session, we gave an example project that could be submitted through Round3. We asked participants to write individual pieces of feedback on sticky notes. This allowed them to give multiple pieces of feedback, and not be influenced by others’ participants feedback.
UI Building Blocks
We also wanted our participants to help us visualize what the interface for Round3 should look like. We gave them “building blocks”, or standard UI elements, and allowed them to position those building blocks to represent their ideal interface for project preview and review. We also provided participants with blank paper and pens so that they could create their own building blocks.
Insights:
The last thing the participants mentioned when doing the UI Building Blocks activity was how they want to directly draw and comment on the project as if they were doing it on paper. Participants mentioned that they would want to be able to circle parts of the project, add comments, and highlight text. We decided to implement this idea into our design. The user would be able to expand the project and annotate it with the several tools provided, including a highlighter, pen tool, and digital sticky notes. This allows more flexibility to give feedback directly on specific parts of the project, and not just answer the required feedback questions.
Design Concepts
- The “Project Name” (whatever the instructors’s official title for the assignment was) is something all the participants agreed was important to include, so the student submitting feedback could remember what exactly the submitted item was expected to be, for example if the instructor was expecting a “10 Page Essay”, but the reviewing student sees a five page essay below the Project Name, that is something that could help them in writing feedback for the submission. We decided that this was something was important to include in our wireframes, due to
group consensus on its importance. - These two elements, a thumbs up-thumbs down rating system for the reviewing student to give their overall opinion of the project, and a section that would show any text annotated or highlighted in the document, were not something included via a group decision. Rather, a participant who was very vocal and more forceful with their opinions, placed these elements in, with little input from the group as a whole and some group members using a more doubting and questioning tone when it was placed in, questioning the effectiveness of the thumbs up-down and highlights as feedback methods, but not outwardly challenging the more forceful participant. We made the decision to not include these two elements in our wireframes, since only one participant was adamant in placing them in the interface and other participants seemed less than enthused with the inclusion to the interface design. Instead, we included thumbs up – thumbs down as an optional rating to give on individual comments they highlight, basically saying “this part of the project was really good” or “this sentence was written poorly”, alongside their typed comment.
- Participants included a zoom in-out option for the document view. The
group almost immediately agreed upon the inclusion of this element upon seeing it as a UI building block option. We decided to carry this decision over to our final design wireframes, as it is a very standard way of viewing a document and provides an option for people who do not want to view a document in full screen, but still would like a closer look. - Participants chose to include an annotation option on the documents, saying that they would like to be able to highlight text and then type directly on the document to leave feedback comments.
- Participants included the download button building block because they might thought students might want to to view the project offline, as an example work for future reference.
- Participants chose to include an “add question” building block, thinking that students may not like current questions or would like to add more questions they thought would be necessary. We chose to not include this feature because we felt that students should not have the option to include extra d questions, that should be the instructor’s privilege alone.
- Participants included a “cancel” button to go alongside the “Submit” button, citing
that a student giving feedback might decide to not submit their typed feedback,
being dissatisfied with it or not done. We made the decision in our final design to
include a variation of this button that says “Save as draft”. We want to help
students to not submit feedback they are not finished with, but we also don’t want
to them to not able to save what they do like about their feedback. We decided to
give the option for students to save feedback and come back later to erase or edit
it. - Participants all agreed to include a question answer format for the feedback. Both
our instructor and our student participants agreed that they would like to include the questions in this way, so they could still see the document as they provide feedback.
Conclusion:
We learned a lot from our first co-design session.
First and foremost we learned that people can have trouble coming out of their shells and making people comfortable can really help the improve the quality and quantity of discussion among participants. There will be people who are more talkative than others and will try to dominate the conversation. It’s important to encourage and ask the opinions of the less talkative participants because they may feel like they don’t have a voice or good ideas. We also learned to be more specific in our instructions for our activities. Even though we asked our participants if they had any questions, they still seemed somewhat confused during the activity. The vagueness of the activities, especially the affinity diagramming, lead to confusion of what the participants should be doing. Overall, our co-design activities lead us to design ideas and features that we would have never thought of ourselves.
Patricia Mata 