JZ Jeff Zych

User Research Interview Tip: Shut. Up.

If you were to look at Robert Caro’s notebook, you would see lots of “SU”s, short for “Shut Up!”, scattered throughout his interview notes. The Pulitzer-prize winning author of The Power Broker, among other mammoth books, uses this trick to keep himself silent while interviewing subjects. About this, he writes:

In interviews, silence is the weapon, silence and people’s need to fill it—as long as the person isn’t you, the interviewer. Two of fiction’s greatest interviewers—Georges Simenon’s Inspector Maigret and John le Carré’s George Smiley—have little devices they use to keep themselves from talking and to let silence do its work. Maigret cleans his ever-present pipe, tapping it gently on his desk and then scraping it out until the witness breaks down and talks. Smiley takes off his eyeglasses and polishes them with the thick end of his necktie. As for me, I have less class. When I’m waiting for the person I’m interviewing to break a silence by giving me a piece of information I want, I write “SU” (for Shut Up!) in my notebook. If anyone were ever to look through my notebooks, he would find a lot of “SU”s.

This is a fantastic trick to use during user research interviews, too. Remaining silent after a person’s initial response often leads them to elaborate more, revealing an additional nuance, or an exception to the “typical” use case they just described.

I take longhand notes on paper for this reason. My note taking never keeps pace with the speaker, so I’m always catching up after they stop talking, which forces me to shut up.

When you’re interviewing users, find your own eyeglass polishing or “SU.”

Interface Lovers Interview

Last week I was featured on Interface Lovers, a site that “put[s] the spotlight on designers who are creating the future and touching the lives of many.” Read my response to their first question about what led me into design.


What led you into design?

In some ways, I feel like I’ve always been designing, and in other ways, I feel like I stumbled into it without realizing it. I’ve been into art and drawing since I could hold a pencil, taking art classes and doodling throughout my childhood. Then in high school, I signed up for a web design class. The summer before the class even started I was so excited that I bought a book on web development — “Learn HTML in 24 hours” — and taught myself how to build web pages. By the time the school year started, I had already put a website online. Being able to create something that anyone, anywhere in the world could immediately see was completely intoxicating to me.

From there, I went down a rabbit hole of learning Photoshop, Illustrator, 3D modeling, Flash, and any creative technologies even vaguely related to web design. That led me to get a degree in Graphic Communication at Cal Poly, San Luis Obispo, with a concentration in new media. Back then (early 2000s), there weren’t many web design programs, and the ones that existed were shoe-horned into graphic design and art programs. Cal Poly’s graphic communication program was the most technical of the bunch.

As part of my degree at Cal Poly, I took a computer science class and learned C and Java. I found programming to be super fun, too and went deeper down the stack into backend technologies and database development. Basically, anything tangentially related to web development interested me, so I took every class I could.

After college, I went down the programming path and got a job as a data warehouse developer. I went technical because the analytical nature of it meant you know if your work is good — it either works, or it doesn’t. I found design to be very subjective and didn’t feel confident that my web design work was “good” (however that might be measured).

I joined a small company, so I was doing database design, ETLs, backend programming, frontend programming, and UI design. Over time I discovered that updating the interface, even minor updates, elicited strong positive reactions and gratitude from customers, whereas re-factoring a database to cut query times in half rarely did. I realized I wanted to work closer to the customer.

I started spending more time designing user interfaces and studying usability testing. I discovered it married the analytical, scientific part of my brain (which drew me to programming in the first place) to the subjective, intuitive part. This was the tool I needed to “prove” my designs were “right” (which I now know isn’t exactly true, but it felt this way back then).

This made me want to formally study design, so I got my master’s degree at UC Berkeley’s School of Information. The program is the study of technology, broadly speaking — how technology impacts society, how it changes people and their lives, and how to build technology with the needs of people at the center of it. The program was great. It only had a few required classes, then you could take basically whatever you wanted. So I took classes that sounded the most fun and interesting — design, programming, psychology, research, product development, business, and more. I learned a ton about product development and user-centered design while I was there.

One of my favorite classes was behavioral economics for the web class, in which we explored how to apply behavioral economics principles to web sites and use A/B testing to measure their impact. That led me to join Optimizely after grad school, which at the time (2012) was just a simple A/B testing product for the web. I started out doing UI engineering, then switched into product design as the company grew. When I officially became a product designer I felt like I fell into it by accident. It was a result of what the company needed as it grew, not my specific career goal. But when I looked back over what led me there I realized I had always been designing in one way or another.

The company was growing fast, so I was presented the opportunity to move into management. I was resistant at first, but when I realized I could have a bigger impact in that position, I jumped on it. Eventually, my boss left, and I became the Head of Design, leading a team of product designers, user researchers, and UI engineers.

After 5 and a half years at Optimizely, I was ready for a break and new challenges, so I left and took some time off. I realized I wanted to be hands-on again and ended up joining Casetext as a product designer. They’re building legal research tools for lawyers, which pushed me to be a better designer because I was designing for people with expertise I don’t have and can’t acquire.

After a few months, it wasn’t the right fit, so now I’m at Gladly managing their product design team. It feels great to be in management again, working cross-functionally to deliver great experiences to our customers, while growing and nurturing the talents of my team.

Read the full interview on Interface Lovers.

What to Expect if I'm Your Manager

This past January I started my new gig at Gladly, managing the product design team. Unlike at Optimizely, where I transitioned into managing people I already worked with, at Gladly I inherited a team who didn’t know me at all. Inspired by my new boss who did the same thing, I wrote a document to describe what my new team could expect from me as their manager. I decided to re-publish that document here. Enjoy.


This doc is an accelerator in building our relationship. It will take a little while for us to find our rhythm, but we can try to short-circuit the storming phase and get some things on the table from the get go. I look forward to learning similar things about you — at your time.

Some of these bullet points are aspirational. They are standards of behavior that I’m trying to hold myself accountable to. If you ever believe I’m falling short, please tell me.

  • My goal is to provide an environment where you can do your best work.
  • I will support and encourage you in doing your best work, not tell you what to do. I want each of you to be autonomous and to make your own decisions. This means you may occasionally make mistakes, which is perfectly fine. I’ll be there to help you pick up the pieces.
  • In supporting you doing your best work, I will help remove roadblocks that are getting in your way.
  • I like to listen and gather context, data, and understanding before making decisions or passing judgement. This means I may ask you a lot of questions to build my knowledge. It also means I will sometimes stay quiet and hold the space for you to keep speaking. It doesn’t mean I’m questioning you, your abilities, or your choices.
  • I don’t like to waste my time, and I don’t want to waste yours. If you ever feel like a meeting, project, etc., isn’t a good use of your time, please tell me.
  • I take a lot of notes, and write a lot of documents to codify conversations.
  • I’m biased towards action and shipping over perfection and analysis paralysis. There’s no better test of a product or feature than getting it in the hands of real users, then iterating and refining.
  • I will try to give you small, frequent feedback (positive and negative) in the moment, when it’s fresh, and in person. I don’t like batching up feedback for 1:1s or performance reviews, which turns those into dreadful affairs that no one enjoys, and leads to stale, ineffective feedback. If you have a preferred way of receiving feedback, please tell me.
  • My goal is to give you more positive feedback than critical feedback. There’s always positive feedback to give. And positive feedback helps tell you what you’re doing well, and to keep doing it. If you feel like I haven’t given you positive feedback recently, please tell me.
  • I like feedback to be a 2-way street, so if there’s anything I’m doing that you don’t like, annoys you, etc., please let me know. If there’s things that I’m doing well that you want me to keep doing, also let me know! Feel free to pull me aside, or tell me in our 1:1s.
  • 1:1s are your meetings. You own the agenda. They can be as structured or unstructured as you want. I will occasionally have topics to discuss, but most of the time your items come first.
  • You own your career growth. I am there to support and encourage you and to help you find opportunities for growth, but ultimately you’re in control of your career.
  • I trust you to make good decisions, get your work done, and use your time wisely. I trust you to not abuse our unlimited vacation policy and to take time off when you need it. If you haven’t taken any time off in awhile, I’ll probably encourage you to take a vacation :) I’m not particularly worried about what hours you work, or where you work, as long as you’re getting your work done (and aren’t working too much).
  • Finally, here’s a list of my beliefs about design.

Adding clarity by removing information

“Where’s the clipboard?”

A customer wrote this in to our support team after using our Copy with cite feature. This feature allows customers to copy snippets of text from a court case, and paste them into the document they’re writing with the case’s citation appended to the end. It’s a huge time saver for lawyers when writing legal documents, and is Casetext’s most heavily used feature.

When I first saw this feedback, I assumed it was an anomaly. The success message says “Copied to clipboard,” but who doesn’t know what the clipboard is? How much clearer could we make the success message?

But then it came in again, and again, and again, until eventually the pattern was undeniable. It was only a small percentage of users overall who were writing in, but it was happening regularly enough that we knew we had to fix it.

The original, confusing toast message that pops up after the user clicks, “Copy with cite.” The original, confusing toast message that pops up after the user clicks, “Copy with cite.”

To debug this issue, I opened Fullstory (a service that lets you watch back user sessions, among other things) so I could observe the people who wrote in actually use the product. After watching a few sessions, a pattern emerged. People would click “Copy with cite,” zig-zag their mouse around the screen, opening and closing menus, then write in to support to ask, “Where’s the clipboard?” (or some variation thereof).

At first I didn’t understand why they were frantically throwing their cursor around the screen. What were they looking for? After watching many sessions, I finally realized what they were doing: they were looking for the clipboard in Casetext! They thought the “clipboard” was a feature in our product, as opposed to the clipboard on their OS.

Now that I understood the problem, the next challenge was how to fix it. How do we communicate that the clipboard we’re referring to is the system’s clipboard? I started rewriting the text, with options like, “Copied to clipboard. Press ctrl + V to paste.” “Copied to your system’s clipboard.” “Copied to your clipboard” [emphasis added].

But none of these options felt right. They were either too wordy, too technical, or just more confusing. I took a step back and re-examined the problem. The word “clipboard” is what was tripping people up. What if we just removed that word altogether? Could we get away with just saying “Copied” instead? For the people having trouble with this feature it may prevent them from thinking the clipboard is a feature we offer. For people who aren’t getting confused in the first place, this is should be just as clear as saying “Copied to clipboard.”

The refined toast message. The refined toast message.

The change felt a little risky, but at the same time it felt right. To validate this would work, I decided to just make the change and see what happens. An A/B test and usability testing would both be correct methods to test my hypothesis, but in this case neither tool was the right fit. An A/B test would have taken too long to get statistically valid results, since the conversion event of “failing” to use the feature was very low. It’s also a difficult conversion event to measure. And a usability test would have been more time-consuming and costly than just shipping the change.

Since the solution was easy to implement (the code change was just removing 13 characters), and the impact if I was wrong was low (the change was unlikely to be worse, and it was easy to reverse course if it was), learning by making a change to the working product was the fastest, cheapest way to go.

After shipping the fix I kept an eye on the support messages coming in. In the following 2 months, only one person was confused about what to do after clicking “Copy with cite,” as compared to the 8 people who had written in in the previous 2 months. Not a perfect record, but an improvement nonetheless!

In this case, the best way to improve the clarity of the UI was to provide less information.

My Yardstick for Empathy

A different perspective by Jamie Street on Unsplash A different perspective. Photo by Jamie Street on Unsplash

How do you know if you’re being empathetic? It’s easy to throw the term around, but difficult to actually apply. This is important to understand in my chosen field of design, but can also help anyone improve their interactions with other people.

My yardstick for being empathetic is imagining myself make the same decisions, in the same situation, that another person made.

If I look at someone’s behavior and think, “That doesn’t make sense,” or “Why did they do that?!” then I’m not being empathetic. I’m missing a piece of context — about their knowledge, experiences, skills, emotional state, environment, etc. — that led them to do what they did. When I feel that way, I push myself to keep searching for the missing piece that will make their actions become the only rational ones to take.

Is this always possible? No. Even armed with the same knowledge, operating in the same environment, and possessing the same skills as another person, I will occasionally make different decisions than them. Every individual is unique, and interpret and act on stimuli differently.

Even so, imagining myself behave the same as another person is what I strive for. That’s my yardstick for empathy.


If you want to learn more about empathy and how to apply it to your work and personal life, I highly recommend Practical Empathy by Indi Young.