I was walking the engineers through the final designs of some admin screens when they asked me this. The page is just a table of objects, with a tab showing the active ones, and another tab showing archived ones.
I hadn’t explicitly designed the “Archived” tab since it was the same basic design as the accompanying active tab – a table. But I told the engineers I would mock it up.
I expected mocking it up to take a few minutes. Boy was I naive! As I mocked it up I discovered a bunch of complexity that I hadn’t anticipated (and the engineers hadn’t anticipated either). What’s the un-archive flow? These objects can be nested inside of each other (like folders), so does un-archiving a parent un-archive all of its descendants? If a child is nested, but the parent is active, how do we display that in the table (on the active tab, children are visually shown underneath and indented from parents, but if the parent isn’t archived the child will be “orphaned” on the archived tab)? If a parent and its children are archived, can you un-archive just a child? If so, where does it appear in the active hierarchy (it will once again be “orphaned”)?
I mocked up these flows and made some product and design decisions to address the above complexity based on what the user would expect in these situations, and what I believe is technically possible based on my understanding of how the feature is being built. I shared it with the engineers and luckily they agreed with my decisions, so we had a happy ending (for now, at least — more unforeseen complexity may pop up while they code it).
The lesson here is that you should always design every screen, even if you assume it will look the same as another similar screen. Engineers appreciate you being explicit, and in the worst case (or best case, depending on your perspective), you’ll discover open questions that need to be addressed.
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.”
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.
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).
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.”
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 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.
The original, confusing toast message that pops up after the user clicks, “Copy with cite.”
The refined toast message.