Now that we’re in a calm moment for VR (especially after the 2016 wave), it’s probably a good time to review the different sets of VR-related usability heuristics out there. From a selfish perspective, I want a list of 5–20 defining heuristics that I can use to guide my design process, and also to provide usability feedback in a structured manner. If you’ve never used heuristics before, you’re missing out (read the first section here). They can become a taxonomy for everyone on the team to discuss usability issues, and they help your team stay objective. It’s time I found this for my VR work.

Here are the criteria that I’m using for this evaluation:

1. Good coverage: Ideally, this is a one-stop-shop for reviewing the usability of a VR app. The heuristics cover both VR-specific, as well as non-VR-specific usability principles that still apply.
2. Approachable: The heuristics can be quickly taught to a non-designer, so that we can use them in a conversation. They’re also brief enough for me to glance at while I’m designing.
3. Hardware agnostic: Different headsets afford different interactions, and new headsets are coming every year. While not perfect, Nielsen’s heuristics managed to survive the internet’s multitude of design cycles, so let’s try to get some heuristics on the book that can work for at least 5 years.
4. Validated: When Nielsen created his heuristics, he didn’t just create a list and throw them out into the wild — he actually presented details on how he built the list using actual research data.

The lists I’ll be reviewing:

• YouTube UX Research team’s heuristics
• Sutcliffe& Gault’s heuristics
• Joseph Gabbard’s VR usability guidelines
• Olga Ivanova’s heuristics

YouTube UX Research team’s heuristics

Heuristic Evaluation for Virtual Reality Systems (page 2)
By Rabia Murtza, Stephen Monroe, and Robert J. Youmans

Good Coverage: 3/5
Approachable: 5/5
Hardware agnostic: 2/5
Validated: 2/5

The YouTube UX Research team developed this list of 9 heuristics based off of a survey of common VR usability issues — a majority being students at the Savannah College of Art and Design. The team acknowledges the flaws in this approach, but nevertheless, it does contain a solid foundation. Not to mention, the heuristics are pertinent to today’s common VR usability issues. I especially appreciate that heuristic #9 basically says “don’t just rely on this list” by referencing Nielsen’s heuristics (although I’d of course prefer that they looped in some of the most relevant of Nielsen’s heuristics into this list).

Unfortunately, the team’s goal here was to create a list that combines hardware and software, so it’s notable that there are only 4–5 heuristics here that a commonplace VR designer can take action on.

Sutcliffe & Gault’s heuristics

Heuristic evaluation of virtual reality applications (page 3)
By Alistair Sutcliffe and Brian Gault, 2004

Good Coverage: 3/5
Approachable: 5/5
Hardware agnostic: 5/5
Validated: 2/5

Sutcliffe & Gault’s list of heuristics is both concise and self-explanatory. Much of the list is relevant for a VR designer/developer today, and it has great coverage of common VR usability issues. Because this list is relatively concise, you’ll be able to post them up on the wall and glance at them as you see fit. It’s also short enough to teach to a developer, in order to make these heuristics a regular part of your vocabulary. It’s also great that this list contains a (just a few) heuristics that can be applied outside of VR, such as with “Support for learning”.

Unfortunately, the methodology for creating the list is a bit opaque — they describe some of the academic sources from which they received inspiration, but it appeared to be a subjective process.

Joseph Gabbard’s usability guidelines

A Taxonomy of Usability Characteristics in Virtual Environments (page 16–35)

Good Coverage: 5/5
Approachable: 1/5
Hardware agnostic: 3/5
Validated: 3/5

Joseph Gabbard’s thesis contains the most thorough list I’ve come across. It’s a collection of 195 guidelines broken down into 4 categories. He developed this list by surveying papers, conferences, online searches, and general discussions with academics in the field. Using his guidelines, you’ll be sure to catch usability issues that you may not have been looking out for. Gabbard’s guidelines also cover usability issues that are not specific to VR, which I believe is really important (see SysInfo1-SynSinfo9 on page 24).

The depth of this list is great for experienced VR designers, but problematic for newcomers (he never intended to make it short, anyways). Each guideline is also relatively brief, which means that some are a bit confusing. You may have to do some additional reading on each guideline if you’re not deep in the VR space. The guidelines also cover hardware considerations, and use-case specific considerations such as collaboration. My ideal list would nix these, but that’s a personal preference. Just be sure to cross out the guidelines that aren’t relevant to your app.

Olga Ivanova’s heuristics

VR Heuristic Evaluation Tool

Good Coverage: 3/5
Approachable: 3/5
Hardware agnostic: 4/5
Validated: 1/5

Note: I know Olga personally, although we’ve never discussed heuristic evaluations prior to publishing. I came across her work when doing my own online research.

Ivanova’s list of heuristics provides great coverage of VR-specific usability issues, although it’s quite long at 64 heuristics. The heuristics are practical (especially for modern VR apps), and are largely geared towards VR app designers. She’s also developed a tool that you can use to jot down notes under each heuristic, which makes it easier to get going with the list.

It’s important to note that she makes no claim as to the scientific validity of the list. She’s an independent VR designer, and it’s up to you to decide if it covers your bases. In addition, the heuristics are occasionally too prescriptive, or unclear. Additional explanation on her methodology for creating this list, as well as more details on each heuristic would be helpful.

Which list should I use?

To be honest, none of these lists quite fits the bill for what I’m looking for. I think it’s important to be able to hand VR designers/developers a single, comprehensive, but manageable list of heuristics that they can use without additional research. While all great in their own ways, none of them checks all of the boxes.

But, that’s just where I stand.

After all, this isn’t a science, it’s an art. Even if the methodologies for creating these lists appears to be rigorous and academic, those methodologies are still extremely subjective. So, thank you to all of the researchers and designers who are pushing the field. Be sure to browse through their work, and pick one list that you think you’ll be able to use repetitively and consistently. The most important thing is to use something to help guide your critical thinking and discussions.

Let me know how it goes! Follow me on Twitter @cgallello and shoot me a DM.

😎,
Chris

Which VR usability heuristics should I use? was originally published in Virtual Reality Pop on Medium, where people are continuing the conversation by highlighting and responding to this story.

The conversation around bridging design + dev always focuses on what’s trendy at the moment — design systems, handoff tools, designers learning to code (what about coders learning to design?). But there’s so much more that you can be doing. I want to share my unsexy, but tactical strategies that have worked for me in my time at Microsoft, Imgur, and Purple.

🧠 Invite your developers to 30 minute brainstorms

Your developers are the ones who are building out the product — they should have a say in what is built. And at some point, they will want a say, so it’s important to proactively involve them. Developers generally won’t be as in-tune with your users as you are, but they can contribute because of their technical expertise and deep knowledge of the product. You’ll also get easier buy-in from these developers about product direction in the future, because they’re able to see how you make decisions in real time (this builds trust!).

📝 Add a line item for “design iteration” into your dev estimates

This is how you end up with really polished software. Add in a 10–20% buffer on your projects depending on the complexity. This will encourage you to sit down with your developer to find areas of the final product to add little delighters. You know what types of improvements can make the biggest impact, and your developer knows what types of improvements are easiest. Find the intersection.

👂 Make it easy for your developers to join in on usability testing

Developers already do functional testing on their own work. But what happens when you encourage them to do a little usability testing as well?

That face to face time with actual users is so motivating. If your developer knows what it’s like when a user is shocked with delight, they’ll be driven to deliver great experiences. You’d be surprised how many extra little animations and time saving interactions can be built by someone who really cares.

How do you entice them to join in? Livestream your usability test so they can listen in while they’re working. Schedule usability testing for the same day/time every other week so people plan around it. Bring donuts. Use evidence from usability tests whenever you make a design decision — the more they hear that usability tests are important sources of truth, the more they will be interested in attending. And if you aren’t able to get them to join in, create a 5–10 minute highlight reel of your recent usability testing videos to at least make sure that they occasionally see users shouting with delight or sighing with disappointment.

🗣 Attend your engineers’ standups

There are a ton of excuses not to do this...but you have to. Your mere presence allows for a few important things.

• It signals that design matters. Full stop.
• It shows goodwill — that you care about what they’re working on.
• You can listen for little areas of your designs that are problematic to build. If you catch that during standup, you can immediately iterate.
• You will learn the language, the mindset, and the process of engineering! Thus making you easier to work with.

And hey. This takes like 15 minutes out of your day. Maybe 30? Just do it.

💡 Show your process

Often times, developers will be caught off guard if you present high-fidelity designs without any explanation or heads up. The more background documents, research presentation, Invision prototypes, and design iterations they see ahead of time, the more they will trust you and your finalized designs. So be sure to use your office space to post up your design process for everyone to see, or use a digital tool that brings that all into one place.

These tips are all about making your developers’ lives easier — but in doing so, you’ll rack up some serious karma points, which of course makes your life easier. I hope it helps! ✌️

🐦 @cgallello

👥 Following and unfollowing

Optimize your follow list for people that help you learn and broaden your horizons.

1. Unfollow people aggressively. It won’t hurt their feelings. If you get lazy about doing this, reading Twitter will honestly suck.
2. And as long as you keep up with unfollowing people aggressively, be sure to follow people aggressively too. Finding the right people who interest you takes trial and error.
3. Don’t just follow celebrities / important people. Follow people who are at the same “level” as you. This is actually my favorite part of Twitter. Like and reply to their tweets. Ask them questions. Congratulate them on things. This is a fantastic way to get to know people, and build up a support network around you.
4. Follow creators. People who share their actual work, whether it’s design, engineering, policy, comedy, illustration, etc. (@azadux, @pablostanley, come to mind).
5. Mute your friends if they’re tweeting stuff you don’t care about, but you don’t want to unfollow.

4. Turn off retweets for almost everyone. Retweets are lazy ways of sharing. If someone has an opinion to share, I prefer to hear it in their own words.

🗣 Tweeting

The Do’s:

1. 🎉 Announce your finished creations. (Avataaars / Photogrammetry masterpiece)
2. 🔨 Share your process and your work in progress. Twitter is a place to be raw.(Woah! / Friday night fun)
3. 💡 Share interesting ideas, analyses, lessons learned, and advice. @sehurlburt rocks this. (Idea / Wisdom / Hot Take)
4. 🤪 Sprinkle in your personality, and things about your life. Even if life is hard right now, and you just need to share how things have been difficult. People want to follow people, not robots. (Personality / Happy / Womp)
5. 📣 Give shoutouts to other people who impress you. Well, doing this is kind of important not just on Twitter, but as a human. (A+ supportin’ @evahoerth and @510home)

The Don’ts:

1. Politics: Don’t, unless you’re involved in politics. UPDATE: Lol, I gave up on this rule. There are so many important issues at play, it feels wrong to stay silent.
2. Negativity: No negative/pessimistic tweets. People follow positive people, not complainers. If I’m about to share something negative, I’ll first complain to my friends on Messenger, then decide if I really want to tweet it.
3. Hashtags: Keep #unnecessary #hashtags to an absolute minimum, they’re bloody annoying. They make it look like you’re #desperate for #likes. Exception is when you’re sharing your work. For example, #screenshotsaturday is a fun hashtag to follow.
4. News: Don’t share news article after news article. Twitter is best when it’s full of good discussion.
5. Retweet endlessly: The occasional RT is fine, but I’ve spoken with other tweeters and the verdict is in — if we see someone who’s just retweeting, we absolutely will not follow them.

💬 Engaging with others

1. Ask questions: Ask questions to those who have more experience than you do. Learn from them. (Clarifying / Questions)
2. ‘Like’ a lot of tweets. It’s a passive way of bonding with someone. Your face popping up in their notifications says “Hey! I’m here and I think what you’re doing is great.”
3. Disagreement: If someone tweets something and you disagree with it, don’t explain to them why they’re wrong. At most, provide an alternate viewpoint. Twitter is not good for heated debates.

Hope this is helpful!

Follow me if you like design or VR. Don’t if you don’t. Bai!

-Chris

Every so often, you come across an engineer who says that “design isn’t hard”. We know that’s nonsense, otherwise every product in the world would be great. But don’t wave off these comments. It’s important to realize that this engineer may not understand the challenges of design. Final designs are supposed to look as simple as possible, which makes it a deceptively difficult practice.

So as a designer, you need to evangelize your work.

If you’re not sharing your wisdom about the ins and outs of the design process, you’re making your life harder. As the designer of a project planning tool for designers (Purple.pm), I’ve taken a proactive stance on this ever since the start. I knew that if our engineering team didn’t understand the work that goes into design, we would never be able to build a polished product. Here’s how I’ve taught them.

1. Walking through my college design projects

I started by showing some real design processes. I no longer had access to my Microsoft/Imgur projects, but at least I could show something. We walked through files in my old Dropbox, but I focused on pulling up the mundane stuff. Early drafts of personas, user consent forms, heuristic evaluation results, videos of user research sessions, etc. This was eye-opening for them. One of my teammates told me he never thought design would be so complex.

Okay! A step in the right direction.

2. Quick presentations and exercises

For a little while, I presented a different topic on design every other week. At the end of some of the presentations, I even included design challenges for them to try out in pairs. The presentations that I gave were:

• Brainstorming techniques
• Constructive design feedback
• User research techniques
• Running a usability test
• Writing good usability testing questions
• Ways designers can command respect
• Affordances and signifiers
• Delighters

By the way, these presentations should be ugly and quick.

• Affordances & Signifiers
• Evaluating designs

3. Teaching Figma

At one point while working, one of my teammates asked how I can always tell if a color is slightly off, or if some padding is a few pixels too large. That got me thinking…it’s time for them to go hands on with a design tool. Then they’ll understand the “eye” for design and the importance of precision.

Over two sessions, I taught them the basics of Figma, and they each worked on a mini-project — finding a mobile app or website and simply recreating it from scratch in Figma. The results are below — I couldn’t be prouder. They did all of the gradients, vector shapes, icons, logos, etc. No copy/pasting.

Team discussions

Occasionally, we’ll explore new products as a team and discuss how we can learn from them. I also regularly share and discuss design articles that touch on new subjects. These ones were particularly interesting for us:

How to write products by Ben Hersh

A Comprehensive Overview of UX Design Deliverables by Nick Babich

When great product teams ship broken UX: 4 steps to mind the gap by Jeoff Wilks

Where does this lead?

After all of this, I notice a ton of little things about my team. They provide better design input, prioritization discussions are more scenario-focused, and they understand a lot more about Purple’s end users.

Over the years, you start hearing some phrases that keep coming up over and over in product or design meetings. They can be indicative of laziness, disorganization, or a poor process — so it’s actually important to address them. Here is my collection of the phrases I’ve heard, and how you can respond.

“Maybe we can A/B test it.”

A/B tests consume a lot of time and effort. Do you really feel it’s worth investing that time? It may be a better use of our time to make a gut decision on this, or find proxy data that we can use now.

“Let’s add that into the settings menu”

How many of our core users will actually need this? Can we instead show this feature only when we think a user would actually need it?

“Facebook/Apple/Google did it that way”

Is it actually helpful to keep our designs consistent with Facebook here? If our users are truly expecting consistency, then that’s fine — but otherwise let’s think more about the right experience for our users.

“We don’t have analytics for that.”

Ok, so what’s the plan for filling that gap in our analytics?

“Maybe we could build this feature idea later on.”

No, it’s better to cut this altogether. We already have a ton of features in our backlog that are higher priority. It’s better to stay focused.

“My friends were complaining about our app this weekend, and they recommended we change X, Y, and Z.”

We can add that to our mental library of anecdotes to pull from, but let’s not change our decision making process so suddenly.

“How about we trigger a notification to encourage our users to do X?”

The world is getting fed up with notification spam. This will just get us blocked by the user. Let’s think a bit more about why they aren’t doing X.

“We don’t want to constrain ourselves. We’re building this product for everyone.”

Making tough design decisions is an order of magnitude more complex without a clear definition on a few types of users to target.

“I think our users are going to like this.”

Hey — you’re usually right, but in this instance, can you elaborate on how you know that?

If you’re spending most of the time in your life building a product, don’t let group laziness mess it up. Be assertive, hold everyone to high standards, and good luck!

Purple boards can be pretty heavy in the DOM — we’re loading all of your documents, designs, prototypes, and tasks on a single project board. But this also means that we need to be very careful with how we implement any animations. When we implemented the redesigned flow for inserting a card into your project, we used a nifty technique that we haven’t seen written about elsewhere. So we thought we’d share!

Here’s what we were trying to build with this project — the ability to insert a card between two existing cards, rather than just at the end.

Our first iteration of implementing this interaction totally failed. The challenge was to animate the expansion of the New Card Menu.

In between each card, we put a 0px wide container for the New Card Menu. On click of the + button, we transitioned the width property of that container from 0 to 400px.

It resulted in a framerate of 2–10fps during the animation. Why? When you change CSS properties like width, height, margin, padding, etc, the browser has to run what’s called “layout”. Because the width of one element may change the width or positioning of another element, which will impact other elements, the browser has to recalculate the dimension and position of every DOM element on the screen. So it’s doing all sorts of calculations. Every. Single. Frame.

The Better Way®

What we did instead involves some CSS trickery, so let’s take it step by step.

1. Click the + button
2. Insert the New Card Menu into the DOM
3. Apply transform:translateX(-400px) on each of the subsequent cards
4. Start animating the translateX property from -400px to 0px on each of the subsequent cards

Alright, let’s see each of those steps visually.

1. User clicks on the + button

Great!

2. Add the New Card Menu into the DOM.

Adding the menu into the DOM will trigger layout, but only once — and it happens before the animation starts. But once we add the menu into the DOM, the subsequent cards will jump over to the right.

Obviously, we don’t want that. So what next?

3. Apply transform:translateX(-400px)
Along with Step 2, we immediately apply transform:translateX(-400px) on each subsequent card. This makes it so that the subsequent cards look like they’re in the same place as when they started. See below.

If you asked the DOM for the position of the second card after applying the translateX, it would still give you the coordinates as if it was still in the pink box. But visually, it’s rendered over to the left. That’s why transform:translate is so great — it doesn’t trigger massive changes to the DOM, so layout doesn’t run.

Alright! Now we can animate that card to the right.

4. Start animating the translateX property
Time to run the actual animation. We simply transition from translateX(-400px) to translateX(0px) on the subsequent cards. Layout doesn’t run every frame, so they smoothly animate.

The tl;dr of our solution

In a nutshell, we add the menu into the DOM, and at the same time, we give the subsequent cards a negative translateX so they look like they’re in the same place. Then animate the translateX for a nice smooth animation.

Closing thoughts

This technique is a serious optimization for a single animation. But when you have a great team, you have the luxury to try to push the browser in new ways. The final animation matches up exactly with our original Principle prototype. You can see it over at Purple.pm — just create a free account and jump into one of the sample projects that you can play around with.

Our previous flow was decent. We had a menu in the corner which had a wonderful staggered-fade animation. From there, a user could select a card type to insert. The whole flow looked and felt nice. But it had a major flaw that only surfaced after the product was being used for big projects.

Before we go any further, if you’re not familiar with Purple, our homepage has a pretty quick explainer and a sample project. This will make the rest of this post more clear.

The Problem

As our users started using Purple for heavier projects, they were telling us that there should be a way to insert a card in the middle of the project. Sometimes they’re going back and adding content that they forgot to add. And in other instances, they were looping back and redoing an earlier part of the project. In order to add a card in the middle of the project, our users were forced to:

• Use the menu to add a new card (at the end of the project)
• Zoom out of the board
• Drag the new card towards the middle of the project.
• Zoom into the new card.

Designing and testing

To resolve this issue, I redesigned the interaction model of inserting cards to be inline, rather than floating on a separate layer. You could still add cards at the end of your project using a big + button. But now, when you hover between two cards, a smaller + button shows up. Here were the Principle prototypes I created:

Usability testing

We tested the Principle prototype with four designers. The biggest takeaway for us was that it was going to be a big change for existing users of Purple — two users couldn’t figure it out on their own. But once we taught them how to use it, they loved it. This was encouraging! In response, I designed a little tooltip that would come up after you’ve inserted a few cards into a project.

This is where we hit a roadblock. After discussing the tooltip with the team, we found that it would take much longer to implement than we had expected. The actual UI is dead simple, but there were tons of edge cases to think through.

• Which two cards should we show the tooltip between?
• What happens if there is only one card visible?
• We know we’ll be building other tooltips soon to teach users, so we need to ensure that we design it and develop it in an extensible manner.
• etc.

Yikes! This brought us to a big decision point. Would this tooltip be worth the investment right away? In thinking it through, we considered one of our driving philosophies with regards to onboarding — be patient. Onboarding is incredibly tricky to get right, so it’s better to wait for actual customer data, and listen to how users describe features in order to craft the perfect onboarding experience. As long as we’re not taking something away from a user, it’s okay if a user doesn’t discover a new feature. No harm done.

So we decided on the following:

1. Ship the feature without any onboarding tooltip.
2. Explain the new UI to existing users by sending an in-app message through Intercom.
3. Watch the data — if new users weren’t learning to insert cards between other cards, then we would implement the tooltip.

An Intercom message is not as optimal as a tooltip pointing you in the right direction, but it ensured that existing users wouldn’t be thrown off, and it required no dev work. We were essentially taking a bet that new users would be fine on their own. These kinds of compromises are tough as a designer, but they’re critical — your design skills are only as good as what ships. And if you can’t make compromises, then you won’t ship anything.

Here’s the message that we showed new users in the bottom right of the screen. This would come up immediately when they opened Purple. Even if the user didn’t read any text, the GIF would have at least caught their eyes and shown them everything that they need to know.

The resulting data

Once we shipped the feature, we watched our analytics to see how the feature was being received. It turns out that our existing users were fine with the Intercom message that we sent out. But only 25% of new users were finding the + button between cards. At the same time, there were some other features that we wanted to explicitly teach users — so we decided that now is a good time to dig in and create the onboarding tooltip.

We built the tooltip such that it appears 10 seconds after the user inserts their third card into a project. We figured that when a user is first starting out, they won’t need this feature — hence why we decided to show it after three cards were created. We wait 10 seconds because there would be too much “UI” coming up if the user inserted a card and a tooltip came up at the same time. Plus, a user is rarely going to want to create a new card immediately after creating a card. We’re also checking to make sure that they haven’t used the feature yet, and that they haven’t seen the tooltip before. There are other edge cases that we accounted for, but that’s the gist of how the tooltip works.

The final, final data

This time around, the data was fantastic. 89% of the people who have seen the tooltip subsequently inserted a card in the middle of a project. Furthermore, of the people that 89% bucket, 50% of the cards that they create are created in the middle of the project, not at the end. As a designer, these numbers were wonderful to see.

There’s a big drop off between the blue and the red because many of our users are “collaborators” — they’ll add one or two cards to their coworker’s project, but not enough to trigger the tooltip. But the green bar is 89% of the red bar.

From a results perspective, an 89% success rate on an onboarding tooltip and high feature usage proves that the feature is useful, and that we are teaching it to the user at more or less the right time.

From a more abstract view, this project was a good example of how a small feature change can be overwhelming. We had to use multiple forms of data input, make multiple strategy decisions based on limited data, and of course, patience. But when you do all of this, you’ll end up with a more polished product, and expanded use cases — for us, Purple is now being used to handle heftier projects by our users, and supports more serious collaboration needs.

The grand lifecycle of a small product change was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a PSA on how to compress videos and GIFs really well for launch emails, onboarding tooltips, homepage videos, etc. This is how we do things over at Purple for all of our promotional material and onboarding videos/GIFs in the app. Disclaimer: I/we have no connection to or stake in any of the software that I talk about below. Just wanted to share what I’ve learned.

Use Handbrake for video compression

Handbrake is one of the most impressive pieces of software I’ve come across. I’m constantly blown away by how much it can compress with minimal effect on the final result. https://handbrake.fr/

For example, I recently compressed a 2.4mb video (exported from iMovie) down to 57kb. WHAT. Prior to Handbrake I would have laughed at compression ratios like that. At the compression that I used, there is a noticeable loss in quality, but only when you flip back and forth between the two. Here are the files:

• Original, 2.4MB (download)
• Compressed, 57KB (download)

Now — I suspect that some of this has to do with the fact that the examples I’m showing use very few colors — but even when I compress actual videos, I see really great compression as well (60–90% from Handbrake). You can generally get the best balance of quality vs size when you set the Quality slider to anywhere between 25-35. You can also crop the video in the Picture tab, which is super helpful sometimes.

Use GIF Brewery + Compressor.io for GIF compression

I’ve used GIF Brewery in the past but didn’t think much of it until I discovered something super strange with it. Ugh this is sounding like “one weird trick!”, but seriously. It turns out the file size can get super small if you use Quicktime for screen capture, GIF Brewery to convert the MOV to a GIF, then run that through Compressor.io for the final compression. I am blown away with how well it works. Oddly enough, Giphy Capture, which is my normal go-to GIF recording software, does not exhibit the same compression ratio. Here’s an example:

• Quicktime + GIF Brewery — 9.3MB (download)
• Quicktime + GIF Brewery + compressor.io — 290kb (download)
• Giphy Capture — 4.8MB (download)
• Giphy Capture + Compressor.io — 3.6MB (download)

The way compression works boggles my mind.

Don’t compress GIFs that you’re uploading to Twitter

This might sound counterintuitive, but Twitter converts all of your uploaded GIFs into compressed video files — which means that your 10MB high quality GIF will end up being much smaller anyways. This doesn’t mean you should simply upload a video though! Even though uploaded GIFs just end up as video files, the way Twitter treats them is a little different. With a video, you have a timeline scrubber and a play button. But when you upload a GIF, there won’t be a timeline scrubber, and it will loop automatically. This is good in many cases. So just think through what experience you want to provide your audience.

Alright, that’s all. Media on the internet is weird, long live the GIF, and best of luck with whatever you use this guide for!

As a designer or PM, it can take time to earn the respect of your peers when having design discussions. One of the best methods I’ve seen is being obsessive about citing evidence during design discussions. The evidence should be things like user research insights, quotes from usability testing, trends in customer feedback, or stats from production data. One of the PMs I used to work with was really good at doing this. He was soft-spoken and calm, but his voice was strong because he regularly cited both usability testing data and analytics data. This made it easy to trust him, so we just questioned him less often. His ability to recall evidence on a moment’s notice was impressive — but not too surprising given how closely he worked with our user researcher and our data scientist.

Learning to cite evidence during a heated debate isn’t easy. It’s a mentality shift. And if you’re like me, you might be awful at memorization. But it’s absolutely possible. Here are three techniques that have been helpful for me.

• Golden Nuggets: Create a central wall somewhere to collect your insights. This wall has to be physical. You and the rest of the team need to see it every day. In one of my design projects, the team and I put up a poster with the title of “Golden Nuggets”. Anytime one of us found something to be interesting or surprising, we would write it up on the poster. During design discussions, it became much easier to refer back to our insights to drive decisions.
• Write your own user research reports: Never just “sit in” on a usability study. If you’re watching someone else conduct a usability study, you should also write up your own report. There’s a big difference between simply tagging along on a study versus analyzing what you heard, putting it in writing, and sharing it with the team. Not only do the insights get imprinted into your brain, but you’ll develop a reputation among your peers for being a true voice for your users. And if you’re worried about overstepping, just make it clear that your report is intended to support the main report — put a link to the main report at the top of yours. Doing all of this helped me develop a fantastic relationship with my user researcher. We even discussed me joining her team!
• Become BFFs with your Data Scientist: In a lot of companies, “data is king,” which means you have to play ball with the data team. This means hanging out with them at lunch, placing silly bets on A/B tests, and begging them to teach you how to build queries. I started memorizing data at Imgur by setting up occasional meetings with my data analyst. We would figure out what metrics were important for upcoming features, and draw graphs on a whiteboard showing how we expected those metrics to change. It was purely conjecture — but it laid the foundation in my brain for it to store the actual data later on. She also taught me how to immerse myself in our analytics software in order to look for trends and interesting stats during my free time. Citing trends that you uncover will make you come across as a source of objective truth, and not subjective opinion.

Think about the people you work with. Are you in the top 10% of people who provide input based on evidence?

Thanks to Morgan Samson, Nathan Bashaw, and Jasdev Singh

“Who do you know that would like this product? What are they like?”

Why? It draws really honest answers out of people because it’s a product question disguised as a casual question about the people they know. Here’s how it does that:

• There’s no social pressure. The premise of the question is that the product is good (for some people) — which means that your participant doesn’t have to give negative feedback. It avoids the social pressure issue entirely. Hooray!
• Strangers are surprisingly happy to talk about the people they know. Here’s a great example. When I was working at Imgur, I was running a usability test on our Android app with a middle-aged woman. She had two kids, two jobs, and doesn’t use social media too often. When I asked who of her friends would like Imgur, she immediately went ‘Ohhhhh boy. I have this friend…he’s always posting all sorts of weird things on Facebook’. Her tone and facial expression was clear — this person is not someone she associates with — and she has no intention of being associated with this app. It turns out, people are fine with sharing honest assessments of other people they know, especially when they don’t know you. But asking them to expressing dissatisfaction for your product in front of you? No way.
• It highlights the people who would be high on the NPS scale. If you ask the question and your user says “I don’t know, I’d love to use the product myself!”, that’s a really good thing. The fact that they’re not thinking of their friends means they’re more excited to get their hands on the product after the study. These types of people will eventually share the product with their friends too.
• It gets right to the personality differences between your product and the user. Every product has a personality. It’s a function of the design of the app, the voice used in the copy, the reliability of the app, etc. You’ll be able to understand how your participant perceives the product’s personality by asking them follow up questions about their recommended person. Are they describing this person as lovely? They probably think your product is lovely. Are they describing this person as someone erratic? Well, your product’s personality might be unpredictable.

Give the question a shot. Let me know how it works, and if you have any other personal favorite questions!