How I once made peace using Gaffer’s tape
I’m Melody, and I’m a Senior Manager of UX Research at Glassdoor. I’m writing to you today because I want to remind everyone that using basic thinking to reveal simple, unsexy solutions can really help you up your game as a master of compromise and peacekeeping on a UX research study.
Good UX research design is about a lot of things. It’s about information gathering, thorough thinking, budgeting, prioritizing, scheduling, strategizing, etc. But one of the nuances of doing it well, which doesn’t really come with experience, is mastering the art of compromise.
Compromise is not the same as negotiation. Believe me, there is plenty of negotiation that happens with research design, and it can be exhausting, bringing parties to a place of agreement with one another and/or with yourself as you maneuver through the infinite universe of option overload while designing the details of a custom UX research project. This process involves identifying the pros and cons of potential courses of action and decisions and deliberating through each one. It can be uncomfortable when there is friction, disagreement, or indecisiveness on the team, but it can also be very inspiring when creative thinking aligns and problem-solving gels.
A beautiful compromise occurs when no one gets hurt, no one loses face, no one gets overthrown, and no one has to look ridiculous by hiding an elephant in the room for the sake of group pride. I’ll tell you one of my favorite stories about how I accomplished this type of perfect compromise by using gaffer’s tape to make peace on a concept testing study for a famous social media native app.
THE PROJECT: A social media app had some new design concepts, two different ways of displaying information for viewers of ‘Stories.’ They were in the habit of doing testing on both iOS and Android, which is a best practice. We kicked off the research and scoped it to recruit both sets of users, with the same usage criteria. We planned to schedule the sets of interviews across two consecutive days so that we could focus on collecting the data about each platform one at a time, compare behaviors and reactions to both UIs, and analyze them in aggregate, as usual.
I have a side question. Why is it a best practice to test both platforms? Is it because Android users feel differently than iOS users? Is it because we want those sentiments to be captured? No, not really. It’s because the interface is different. Information is placed differently, rendered differently visually, and different navigation options on the device create different usage habits and instincts which vary by platform. Essentially, the platform of use varies to such a degree that we learn different things when we look at the designs in both places, so we do that!
THE SITUATION: Once we saw the draft design concepts we noticed something VERY WEIRD. They were rendered with an Android device UI bottom bar navigation on an iPhone. At first, we thought it was an odd “kitchen sink” design which was emerging towards the two renderings, so we asked about when we would receive the final designs for each platform. But the designer said: “This is the design. We’ll be using this same prototype for both iOS and Android.” That was a STOP before you reply moment for me. I had my thoughts…so the plan is to disorient every user during the test? The Android users will be looking at a narrower screen and using unfamiliar hardware (iPhone 7 or 8 home button was standard for testing), and the iPhone users will have the option to use the bottom navigation bar for the Android app, which they would never see or use on their iPhone app. This plan was going to create what we call “false negatives” (problems which don’t need solutions because they aren’t real) by testing an unrealistic UI, especially on iPhone.
THE QUESTION: I did some eye-rolling for a while and had a snack. Then I re-wrote the clarifying question over and over again until I felt like I couldn’t hem and haw any longer and had to send it: “Is there a reason why we want to use this hybrid device interface, where every user is either using unfamiliar test hardware (Android users) or interacting with an unrealistic UI (iPhone users)?”
THE ANSWER: They replied saying that they were working on their global empathy across the design team, who were in the habit of designing “iOS first” experiences, and needed to think about Android more often, because more of their users, especially International users, were on their Android app. They wanted to remind themselves that Android was their base case and iOS was their edge case, essentially. Makes sense. But…they also had a mandate to use their own proprietary prototyping software in order to save money on licenses for other products, because their design organization was so large, and licensing is expensive at scale. This prototyping tool only works on iOS. Therefore, they had gotten into the habit of rendering the Android app on iOS.
THE INSPECTION: I asked our IT manager to download the proprietary prototyping tool and the test link to the test device I had reserved for this project. We cruised through the prototypes and I explained our puzzling plan to him. Saying it out loud made me feel better. And he understood.
THE INSTINCT: Since he is a skilled A/V guy, he is also well-versed in setting up equipment, stabilizing it, doing fussy things like propping up cameras on boxes, little band-aid fixes, etc. I recalled his many lectures about the wonders of “gaffer’s tape” — that black tape that A/V people love because it can secure anything in place (especially cords a person can trip over), and then it can be removed without a trace. It also happened to be black, which matched the screen of the test iPhone. So I turned to him and said, “Can’t we just cover this distracting navigation bar for the iPhone users so they never see it or touch it? And then remove it for the Android users?” And he said “Yup. Let’s cut this tape to the right size right now. If they are cool with it, that’s all you need.”
THE COMPROMISE: I told the design team we had successfully rendered the prototype onto our test device and set up a preview meeting with them to QA it. During the preview QA meeting I started by saying: “ For our Android users I’ll orient them to the iPhone test device a little, because we aren’t focusing on hardware. I don’t even think they’ll need to use the home button during the test, so we’re fine with showing them the Android UI on iPhone.” “For the iPhone users, however, I have this little piece of gaffer’s tape which I will adhere to the device and cover up the bottom navigation in the UI so that they never see it. This way they won’t use it in the test and we’ll see what their real behavior would be with these designs when navigating. Is that ok with you?” A resounding “yes — sure” was heard by the team. Then I said: “I’d like to do the iPhone sessions on Day 1 because they’ll have the most realistic experience with this navigation covered up, and then on Day 2 we can test with Android users who will need to adapt to the hardware.” They said “cool.”
THE RESULTS: My sessions went smoothly. The team watched and listened eagerly so they could focus on their real question, to determine which design concept made more sense for the Stories viewers! There was very little distracting data, no one was embarrassed, no one had to defend a silly testing plan, and the design moved forward with a sense of camaraderie and trust.
THE LESSON: Right here in Silicon Valley, we used something physical to solve a digital problem. We made something very complicated very simple. And we protected the team from collecting strange data that could be exposed and challenged by their leadership. Pure harmony!
