Remote Communication and Me
Or: How I Learned to Stop Worrying and Love the Double Diamond
Coffee in hand, I clicked the Zoom link to log into my User Experience Design Immersive classroom. Slack was open and active, Google Drive sat on my monitor with class resources at the ready, and two notepads laid in front of me, eagerly awaiting knowledge and insight. It’s only fitting that our first project would focus on one aspect of remote collaboration within an existing app, to support the remote experience.
Discovery
We started the research process the same way we start any endeavor: with assumptions. Once I knew the focus was the remote experience, I started listing out beliefs I thought were collective to anyone WFH or attending Zoom U:
- No one likes doing things remotely! They would much prefer to be in person!
- Tech issues make remote work a hassle
- People have a clear sense of what apps they love (i.e. Zoom) and what apps they hate (i.e. Skype)
- Those who are new to remote work will struggle more than those with experience
In getting the assumptions written out, we’re able to convert them into questions for user interviews and start removing ourselves (and our biases) from the research:
- How long have you been working remotely?
- What does a typical day of remote work look like?
- What tools do you use daily to facilitate working remotely?
- How would you rank the tools you mentioned from best to worst?
By the end of the project, I’d learn just how important it was to get the assumptions and questions right. The solutions we create as designers are based on these questions and the following interviews; get the questions wrong and you’re solving the wrong problem.
When we first learned about user interviews, it was stressed that we should ask to record them each time if possible. I knew it would mean I could immerse myself in the conversation and avoid keeping my head in my notes, but I underestimated just how valuable it was to go back to the recordings. Threads asking to be pulled would sit, untouched, as I moved on to the next question in my discussion guide. Wait!, I’d beg, but Zoom Gabe was on a mission to finish asking each question in the guide, missing valuable moments to dig a little deeper, maybe ask Why? one more time.
Thankfully, I did pull on enough threads and spun enough yarn that observations started to pile up. Digital Post-it notes were color-coded for each of the four interviews I conducted, making them feel as real as the people I spoke with. It was time to do some affinity mapping.
Definition
Each note on my Miro board was a single observation or quote from an interview, a thought that would join others as I sought to find some trends among the conversations. The trends (on blue notes) would be the basis for my “I” statements, which in turn would feed into insights.
Affinity mapping led to some key takeaways for me:
- Remote work is new to part of the workforce, but that hasn’t made the transition to remote work impossible during the pandemic. There’s plenty that users like about remote work!
- Users miss having the office as a separate space to do work and connect with peers, as well as providing some built-in work/life balance.
- The tools users have to work with fall broadly into the following categories, with some overlap: industry-specific apps; conferencing tools; instant messaging tools; email/email managers.
- Some of these tools are only being used to facilitate teamwork during the pandemic while others are staples of the users day-to-day. The technology they used in the office is often what they’re using in remote settings.
- Users have some technical aspects they have control of (i.e. their Internet provider, the physical layout of their workspace and gadgets), but some are understandably out of their hands (i.e. having to use a VPN, limitations of the software they’re using)
These insights were helpful, but we needed to keep a user in mind while drafting our problem statement. This is where the above thoughts and observations need to be represented by an amalgamation of the users I talked to, preventing any biases from creeping into the design. Let’s meet Marcus.
Like the users I talked to, Marcus is struggling with interruptions at work. The conversations he had over lunch or in the hallway are now the IMs and emails he gets while he’s trying to focus on getting some bigger chunks of work out of the way. Marcus’s quote is something I heard in multiple interviews: “I feel like I’m working all the time now”.
With Marcus in mind, I could craft a problem statement that would guide our design based on the user’s needs and pain points. Here’s the problem statement I used:
During the first wave of the pandemic, several workers went remote for the first time in their careers. This resulted in confusion about methods of communication and work/life balance.
Marcus is struggling with giving his team and clients a clear sense of when he’s working and how to best communicate with his immediate team.
How might we help him regain control of his schedule and create clearer communication across his tools?
The problem statement gives us a clear goal in mind but doesn’t focus on a single solution. What I ultimately chose to pursue could have easily been replaced by another solution, so long as it stayed true to the needs and pain points of Marcus and the users he represents.
Design
Problem statement in hand, I chose to focus on Microsoft Teams. It was a tool that nearly every user I interviewed spoke about using, though each had varying opinions on its use. The one constant was the idea of “interruptions” and so I started by looking over the interviews again to see if there was an aspect of Teams that would benefit from a slight tweak.
Team’s chat function has 6 (!) different statuses you can set yourself to, with each one determining how you receive messages and serving to influence how other team members might interact with you. What if one of these served to influence your teammate's behavior as well as yours?
I gave the concept the name “Delayed Delivery”. The status works by delaying messages until you become available again, in the hopes that both the sender and the recipient would keep the other in mind. Here’s what the paper prototype looked like:
The paper prototype delivered some key takeaways after usability testing:
- The initial design included an ‘X’ for users to cancel Delayed Delivery with ease. This was confusing, though, because users expected to revert their availability the same way they changed it.
- Users expressed some confusion about the feature and wanted information available in the toolbar.
- Users were surprised by the new messages simply popping up. They wanted to be able to click on the respective chat and see the messages afterward. Y’know, like any other chat app.
One thing was clear: usability testing is invaluable at every stage of prototyping. If we had time as a class, I have no doubt several students would update their paper prototype and test again, simply because of how quick it would be to erase some lines instead of pushing pixels.
I felt ready to move into a mid-fidelity prototype. I’d take the lessons above and apply them to the design, hoping to also emulate Teams a little more in the next iteration. Here’s what that looked like:
Though visually cleaner than the paper prototype, the mid-fidelity prototype had its own issues going into usability testing. For one, the prototype looked a lot like a beige version of Teams, which was great for anyone who knew what Teams looked like, but affected the experience for anyone who didn’t:
- More than one tester asked if they could click the X on the sidebar to close the tab
- Each tester was able to complete all 3 tasks requested during the usability tests, but all 3 testers needed a moment to find the Availability menu in the upper right-hand corner
- Though there would have always been no color in a mid-fi, using letters to demonstrate availability was not an effective substitute. No user noted the letters in their availability changing (more on that in a bit).
The testers also pointed out parts of the UI to ask what they did. Some were intuitive, but for others, I found myself asking why I included it. If it doesn’t serve the goal or purpose of your user’s task, it probably shouldn’t be part of the mid-fi.
The tests also revealed I hadn’t considered scale when working in Sketch. As I noted in the slide above, allowing the design to scale up for users with different screens would have made things much easier for the tests, especially if the users are using any sort of accessibility features on their devices.
Ultimately, the usability tests were successful. Users were able to intuitively change their availability and see their changes work in “real-time”. Once they knew where to look, it was a delight to witness users click through menus as if they had been using the app all along. If we had the time to do so, I would have loved seeing how users would have responded to the next iteration of the prototype.
Deliver(ance)
As far as next steps go, I think it’s time to add color to the mix. Users need something to draw their attention to their availability and color serves to both communicate status as well as draw the eye to where it needs to be. The testing script should also focus on what users have leaned on to determine their availability on mobile apps vs desktop apps.
The name of the feature may also change, something that might call for A/B Testing. The focus of the feature, however, will likely stay the same, at least for another round of testing or two. I’m confident that if it works for Teams, it may well be something we can look to expand to other chat apps. As one user put it during their usability tests:
The more I think about the concept, the more I like it. I don’t have to worry about getting the message, my coworkers can respect my time for work, and I don’t feel tempted to check messages.
If I learned nothing else from this project, it was just how strong the methodologies we had learned over the last two weeks are. True to its name, the Double Diamond is both rigid and beautiful to behold. I’m confident that the next opportunity I have to put it into practice will build upon the experience of the first, iteration upon iteration.
That said, this project also confirmed that I came into this class with (relevant!) preexisting knowledge. When it came time to do the interviews, I was able to lean into my previous work to create space for conversation. I was able to go back and make inferences from the usability tests and interviews to inform my designs. I may be new to users, but I’ve had the pleasure of working with people all my life.
