OP Design

Date: April 27-29 2020

What: Remote Hackathon organized by Microsoft & BrainStation

Problem Space: Working from home 

Team Composition: 3 designers, 2 data scientists, 3 web developers

My Role: UX/UI Research & Design 

Design Tools Used: Figma, Zeplin, Pen & Paper 

General Tools: Google Scholar, Microsoft Teams, Slack, G Suite

End Products: 

• Web prototype of a task manager & accountability partnership system integrated into Microsoft Teams. See our final submission here

• A slide deck showcasing our work (to be reviewed by the judges)

• A 3-minute pitch presentation with an associated presentation deck

Overview

This was the first remote hackathon I ever participated in (and my second hackathon overall). Around 150 people from Toronto and Vancouver organized into 22 teams - each with slightly different constellations of designers, data scientists and web developers. 

In the beginning of Day 1, we were given the problem space of working remotely - a relevant topic during the COVID-19 pandemic. The only instruction we got was to present and submit a concept or prototype aiming to improve working from home by the end of Day 3. After spending a day ideating and researching, my team and I converged on prototyping a task manager and accountability partner system to be implemented into Microsoft Teams. 

I will start by recounting the highlights from each day, followed by a retrospective.

“You have 3 days to create a digital prototype and/or solution to support a better work from home (WFH) experience”

The Kickoff 

Apart from one fellow Vancouverite, my team comprised of 6 Torontonians. All in all, there were 2 fellow designers, 2 data scientists and 3 web developers. So, lots of new faces. After having done our introductions, we got right to it. We went around the (virtual) room, expressing what kind of frustrations we ourselves had encountered from the social distancing policy, and working/studying from home (WFH). 

Morning Brainstorm

From our very first interaction, there was some foreshadowing of what came to be our solution concept: when we went around the room, some WFH frustrations expressed were: 

• Inadequate ability to virtually network with other industry professionals

• Losing track of time

• Forgetting to exercise and eat, or otherwise take breaks

• Lack of accountability, because there's no social reinforcement from colleagues

• General lack of social interaction with colleagues

From this, we could distill 3 themes: 1) the breakdown of habit; 2) accountability; and 3) lack of social interaction. While these themes came to be the focus of our solution concept, we weren't quite ready to converge on a solution yet. 

Divide, Conquer...

We broke off for 1.5 hours to individually research whichever of these issues we wanted. I decided to focus on issues related to setting up tasks and being held accountable for completing them. This was close to my heart, as I am part of a self-improvement group where we have an accountability system in place.

Down the Rabbit Hole: Secondary research 

Accountability

Accountability partnerships have been great for me: they increase my productivity, help me hone in on specific tasks, and subsequently complete them. But for this project, I wanted to know why. This led me down a rabbit hole of social psychology, particularly principles of influence, as defined by Robert Cialdini. Two of these principles were especially interesting: reciprocity and social proof. Reciprocity simply refers to a person's inclination to reciprocate an action -- essentially the feeling of owing someone. In the context of accountability: if you're checking in with a partner, and your partner has completed his/her goals, then you feel the need to reciprocate by completing yours too.

The other principle, social proof, is the inclination to model others' behaviour on the assumption that it works for them. Here's how I reasoned it related to accountability partnerships: if you're in an accountability partnership, you check in with each other's progress. This creates a conversational schema, regarding expectations of how and when to act. The literature suggests that this effect has a stronger behavioural influence in larger crowds (social proof is sometimes also referred to as the consensus effect). So, if we were to implement some kind of accountability system, it could potentially be made more effective if the user could monitor the progress of multiple people. A bit of foreshadowing: this reasoning came to be useful later on when we as a team decided on what type of solution to implement.

Productivity

I also looked at the domain of productivity more generally. I looked at habit tracking apps and organizational practices meant to enhance productivity. In doing so, I stumbled across nudge management theory. Nudging refers to the altering of human behaviour through indirect suggestion and positive reinforcement, as opposed to direct enforcement. Nudge management theory is the principle put to practice in businesses and organizations. Essentially what it comes down to is the subtle altering of choice architecture as opposed to direct enforcement of rules. Google was commonly cited as an organization making use of the theory (e.g. Freibichler & Ebert, 2017). A habit tracking app called StickK was also based around the concept of nudging.

Perhaps there was a way to combine principles of influence and nudging into our project...

...and Reunite

After 1.5 hours we presented our research and our ideas. A few interesting concepts were presented. One of the data scientists, Carlo, floated the idea of a job application keyword-checker, where you could see how well your resumé matched keywords from a job description. After some team discussion, we decided that the idea strayed too far away from the problem space, i.e. working from home. One of the other designers, Natasha, had focused her research on interviewing people in her network about their frustrations with working from home. Her findings corroborated the themes we had identified in the morning: lack of accountability, losing track of time, and breakdown of habits.

After brainstorming for another hour or so, we eventually decided to focus on a concept that dealt with managing tasks and being held accountable for them. We knew we wanted this to be used by employees of a company. But we still weren't sure what to make. There are hundreds of habit tracker- and task management apps out there, so how could we make our solution original? Moreover, how could we touch on our third theme of interest, i.e. that of social isolation?

To focus ourselves further, we formulated a design question:

How might we facilitate employee accountability while alleviating social isolation?

Eureka! 

By now we were 7 hours into the hackathon. It was clear that we were all getting tired: it felt like we were going around in circles trying to come up with a solution that would be feasible within our time frame. 

But then it hit. In the midst of all our exhausting back-and-forth, Nelson, one of the developers, suggested that we could implement some function that randomly assigned users to an accountability partner. This was brilliant! From this suggestion, a solution was crystallized:

A work platform where teams of coworkers would be able to set up daily tasks (and their supervisor could add tasks) check their progress on their tasks, and be randomly assigned to an accountability partner daily. This touched on all the themes:

• The random assignment will help ensure that people actually complete their tasks (after all, what if their accountability partner for the day is their supervisor?)

• If the user's work team is really big, then the random assignment will eventually pair them up with someone whom they haven't spoken much to, thus encouraging social bonding

• Seeing other's progress on their tasks will further nudge a user to complete theirs (through social proof)

I suggested that we build a prototype within a Microsoft application, so that us designers could make use of their publicly available Design System and UI Library (Fluent). My thought was that this would greatly speed up the design & development process, which would allow us more time to think of functionality. We decided to go for Microsoft Teams. 

Now we were off to the races. 

Early Morning: Applying Past Insights   

Because of all the time we spent on coming up with a concept on Day 1, we had essentially done most of the heavy lifting. Now it was just a matter of doing the work. 

The reason why I suggested to build a prototype within an existing Microsoft product was that we could then use Microsoft's design system, Fluent. That way, I and my fellow designers could quickly create high-fidelity mockups to be handed off to the developers. I did this because of a valuable lesson learned from my first ever hackathon: web developers are the gatekeepers. What I mean by this is that, if you're prototyping a concept for web, you have to be mindful of the time effort it would entail from a development perspective. In my first hackathon, we designers and data scientists had very lofty ideas for a solution concept and we dove deep into building our aspects of the work -- only to have the developers waiting for us to be done. This caused a lot of undue stress for the developers, who had to scramble to get the prototype done on time. 

Game Plan

My design partners and I set up a Figma project to be shared amongst ourselves and the developers. We mocked up all the components of the Microsoft Teams UI that already existed. This bought us designers some time to think hard about our chosen concept and how to implement it. By 11 am, 70% of the prototype was ready to be coded; which meant that we could spend most of the rest of the day working out the kinks for our concept.

Because our concept didn't have a clear link to data science as it stood, the data scientists were a bit unsure as to what they could do to contribute to the project. After some discussion, we agreed that they would focus on researching the problem space more, finding data that could provide a more steady empirical justification for our concept but also potentially reveal demand for additional functionality. They then set off to analyze sets of tweets with the hashtag #WorkFromHome.

We decided on times for us to check-in as a whole team, but otherwise, we started working on our individual aspects of the project.

Midday

My fellow designers and I decided to divide and conquer, by focusing on different UI aspects of our concept. We made a list of the things we wanted to implement:

• An additional menu tab where a user could set up their daily tasks

• A progress bar where a user could see how close they are to completing their goals

• A submenu tab where the user would be able to see who they are paired up with for the day, this person's tasks, how close they are to completing their goals, and a CTA to message them

• Modal indicating that another user has completed a task, with a CTA allowing a user to send encouragement/congratulate this other user

• Toast indicating that a supervisor has added a task to a user's list

I decided to focus on working on designing the new menu tabs, copy, working out the information architecture for the content within these. Also, I took on the role as the person to liaise between the disciplines. I wanted to touch base with the data scientists about how their research was going, and I would also prepare finished UI components to be handed off to the developers via Zeplin.

Evening

Around 6 pm, our mockups were complete. The developers were still working away at coding them, and the data scientists had completed their first analyses --using a BERT prediction model to analyze the emotional valence of 14000 #WorkFromHome Tweets (negative, neutral, positive). They had also produced a word cloud of the most frequently occurring words in that dataset. The analyses yielded that around 1000 of these tweets were negative in affect. This was interesting to me, as I saw an opportunity for us to create a persona based on this data. So I asked the data scientists to take just the 1000 negative Tweets and produce a word cloud from those, so that us designers could create empirically justified frustrations and motivations for a persona. 

The key words that were returned were very helpful, as they supported our initial research into the problem space: words like "miss", "isolation","problem", and "challenge" were frequently used -- which seemed to hit our identified topics of social frustration and lack of productivity. 

End of Day Meeting

We all later reconvened as a whole team to check in on everyone's progress. We set up goals for what to complete by end of day. The developers were content with working late on building out the prototype. I took on the tasks of handing over all assets to the development team, to create the content and overall structure of our upcoming presentation, and to write up a long-form rationale of the project so that the team could refer to it if they ever became unsure of what was going on. Chloe and Natasha, my fellow designers, took on the tasks of designing the slides for the presentation as well as creating a persona based on the data provided.

The Final Push

We started the day early with a team-wide check-in. The web developers were still busy building the prototype but they seemed well on their way to completing it before the submission deadline (which was in the afternoon). Both the data scientists and us designers had done the bulk of our work at this point. What was left for us to do was to finalize a 10-page presentation deck of our project, as well as prepare for our 3-minute concept pitch. 

Because the presentation would only be 3 minutes, and would be delivered remotely, we decided it would be most efficient to elect just 1 presenter. Chloe took on this role. While she was practicing the pitch, Natasha, Carlo and I decided worked together to finalize the 2 slide decks.

Presentation Time

It was now 2 pm - time for all teams to present their solutions to the problem space. While there were some technical issues - frozen screens and faulty mics being the main culprits - the presentations largely went off without a hitch. Chloe flawlessly presented our pitch and did a live demo of our web prototype. 

It was interesting seeing all the other teams' responses to the problem space: there were game concepts, other accountability systems, mental health apps - a wide range of concepts. Seeing all the presentations felt like a well-deserved culmination of 2.5 days of hard work. 

Thoughts

The first thing I want to mention is how proud I was of my team. I felt like we came together to create a really exciting concept in less than 3 days. There were no conflicts, no egos - just a shared motivation to create something! I think we were able to pool all of our respective skillsets together in a very efficient way. I was also impressed by how close the developers came to recreating our mockups.

Looking back, our success can largely be attributed to 4 things:

1. The exhaustive ideation and debate we did on Day 1: spending pretty much all of the first day researching, presenting ideas, going back and forth vetting ideas, helped us distill a clear idea of what we aimed to build. In other words, by Day 2, we had a very clear idea of what we intended to build -- with minimal backtracking.

2. Design & web development working in parallel: using Microsoft's design system allowed us designers to quickly create hi-fidelity mockups of most of the UI. Using collaborative tools like Figma and Zeplin allowed the Web Devs to get started pretty much right off the bat. I think this was a key factor in reducing potential stress among the team.

3. The willingness of everyone to take initiative: everyone in the team was very eager to contribute. There was no waiting around to be delegated a task; rather, if I or any of my team members recognized something needed to be done, we would take on the task personally. I think this willingness to take initiative may have been the result of how the 2 above points cultivated high team morale.

4. Intermittent check-ins: while we spent lots of time doing individual work, or breaking up into smaller discipline-specific meetings, the team-wide check-ins were indispensable. They ensured that everyone was up to date with how far we'd progressed, and created a forum for declaring what needed to be done next.