Our initial approach consisted of understanding the scope of our design space - meetings in modern companies. We explored this problem space through a variety of research methods– competitive assessments, surveys, secondary research, semi-structured expert and user interviews.
After research and synthesis, we moved on to ideation and prototyping. Once we tested and evaluated our concepts and prototypes, we refined the final design.
This section of the case study shows the methods and process we took in creating "Toki."
In order to better understand our problem area, we conducted a competitive analysis of 8 existing tools that either function within the working environment or focus on improving the meeting experience.
We analyzed Asana, SharePoint, Confluence, LessMeeting, Voicera, Quip, Meetin.gs, and Basecamp. These applications were examined for their features, information architecture, and user interface.
View Competitive Assessment ↗
The survey was distributed via e-mail and social networks to those who are currently working or have working experience in the United States. The survey also served as a screening to recruit users for interviews and testing.
What We Wanted to Understand
The survey was conducted to gain an understanding of people's perception of their own meeting experiences.
What We Found
Our survey results (based on 200+ responses) showed that multidisciplinary meetings occupy at least 20% of all the meetings respondents attended last month. In response to the most common challenges of meetings, 43.3% chose “keeping meeting focused and on track” and 38.3% chose “coming to decisions”.
Expert and User Interviews
After synthesizing our survey results, we proceeded to engage in user interviews. Per the survey responses, we felt that there was much to be uncovered in the space of communication in meetings that involved people of varying levels of knowledge. We selected 12 survey respondents and reached out to a handful of experts in the fields of meeting design and organizational science in order to get more intimate, experiential knowledge into this problem area.
Our experts included employees from the Microsoft Evisioning Center and Kevin Hoffman, a leading expert on meeting design. The experts helped us identify problems with current approaches to meetings while sharing their personal experiences with meeting pain points.
With our content neutral mentality, we intentionally selected participants with varying backgrounds and geographical location. Selection was based on open-ended responses in the survey. Our user interviews helped gain intimate knowledge into the pain points within meetings as well as an understanding of some of the consistent problems.
We created an affinity diagram to organize and synthesize the interview data.
The blue notes represent themes of findings; yellow notes represent evidence from users; red notes represent insights.
To represent our findings, we developed a synthetic model. The model illustrates the problem of fluctuating engagement levels within meetings that are a product of distraction and knowledge gaps. We developed three personas to illustrate this paradigm.
The Facilitator's engagement level is relatively steady throughout the meeting.
The Contributor's engagement level is high when he presents content and answers questions.
The Uninformed is not familiar with the Contributor's content and contributes to divergent discussions throughout and after the meeting.
After synthesizing our research and identifying our problem space, we formulated a set of design principles to take with us to ideation and prototyping.
Increase engagement during the meeting.
The solution should prevent attendees from multitasking during meetings.The solution should find a way to encourage attendees’ individual input.
Bridge the knowledge gaps between attendees.
The solution should create a collective resource that everyone can refer to.The solution should make sure everyone understands a little bit about each others’ discipline to make an informed decision.
Promote individual awareness of context
The solution should provide context during the meeting to help attendees to be aware whether they are off topics or not, and help them to stay on track.The solution should inform the attendees the current state of the meeting.
Optimize individual expression.
The solution should help attendees testify disagreements through a concrete representation of each other’s understanding.The solution should help attendees to express their opinions to be understood by other people.
Facilitate independent comprehension of the meeting’s content.
The solution should make sure each attendees walk out with an actionable item. The solution should document important moments for each attendee in order for them to reinforce attendees’ personal transient memories as trackable data.The solution should provide resources for future reference.
View Full Research Report ↗
Ideation and Evaluation
We sketched out 108 concepts total. From the 108 initial concepts, we narrowed down to 5 concepts to move forward with prototyping.
Down Selection Criteria and Rationale
We narrowed down from 108 concepts to 5 concepts based on the principles of viability, desirability, and feasibility, and made paper prototypes for the 5 concepts.After testing the paper prototypes with 4 designers and 1 engineer who work in tech companies, we reached three insights to drive our final design direction.
Self-documentation can distribute accountability to each individual and thus can be useful in the future.
While auto-transcription of meeting conversations can help attendees trace context, reading long transcripts is distracting during meetings.
Whiteboarding and other forms of assets sharing (rather than slides) are common especially at the early stage of a product cycle.
View Concept Evaluation Report ↗
Based on the results of the low-fidelity prototype testing, we revised our concept to be an "interactive timeline," and used InVision to build our mid-fi prototype. We tested the prototype with 2 designers and 3 product managers (age 25~50).
What we wanted to understand
How our target users would interact with the prototype.
Their insights on the concept of an interactive timeline.
Three out of five intended to type notes under “Notes” section and ignored the button "Mark Notes."
Three out of five participants thought it would be too much work to click, highlight, and make notes during meetings.
Four out of five participants and didn’t realize the differences between “Mark Moment” and “Mark Notes.
Three out of five participants did not notice the collapsing button when requested to collapse the timeline.
Three out of five had trouble returning to the timeline to click notes. They’d prefer to click the timeline and see notes and details of the moments on the same page.
Three out of five had concerns about overcrowded content on the timeline. They wanted to filter for specific person or certain time range.
Two participants thought the notes were others’ notes because they’re under different names.
Two participants found it acceptable to have access to complete transcriptions of meetings. Three participants had privacy concerns. Only seeing moments of transcriptions instead of the complete transcriptions in “moments” might reduce such concerns.
High Fidelity Prototyping
Through our medium fidelity prototype testing, we realized that we needed to:
- Unify the experience of approaching sections (timeline, notes, and transcriptions.)
- Improve the visual communication of UI elements.
- Minimize the efforts to make personal notes and learn context during meetings.
- Modify the flow of accessing a previous meeting.
- Reduce privacy concerns of auto-transcription.
1. The timeline lacks clear visual cues for users to recognize “moments” and “public notes.”
2. Users cannot tell whether the avatar photo represents a task owner or an assigner of the task at a glance.
3. Users’ perceptions of color labeling vary across roles and companies.
To represent the product and showcase the main features, we developed a user flow.
To further refine the design system, and make it developer-ready, we red-lined the application.