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.
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 recommendPractical Empathyby Indi Young.
In 2018 I read 23 books, which is a solid 9 more than last year’s paltry 14, and 1 more than 2016). I credit the improvement to the 4-month sabbatical I took in the spring. Not working really frees up time 😄
For the last 2 years I said I needed to read more fiction since I only read 3 in 2016 and 2 in 2017. So how did I do? I’m proud to say I managed to read 7 fiction books this year (if you can count My Dad Wrote a Porno as “fiction”…). My reading still skews heavily to non-fiction, and specifically design, but that’s what I’m passionate about and it helps me professionally, so I’m ok with it.
I also apparently didn’t finish any books in January or February. I thought this might have been a mistake at first, but when I looked back on that time I realized it’s because I was wrapping things up at Optimizely, and reading both Quicksilver by Neal Stephenson and Story by Robert McKee at the same time, which are long books that took awhile to work through.
Story: Substance, Structure, Style, and the Principles of Screenwriting
by Robert McKee
I’ve read next to nothing about writing stories before, but Robert McKee’s primer on the subject is excellent. Even though I’m not a fiction author, I found his principles for writing compelling narratives valuable beyond just the domain of screenwriting.
Published and edited by Victionary
There wasn’t much to “read” in this book, but it was full of beautiful hand-lettered pieces that continue to inspire me to be a better letterer.
The Baroque Cycle
by Neal Stephenson
Neal Stephenson’s Baroque Cycle is a broad, staggering, 3-volume and 2,500+ page opus of historical science fiction, making it no small feat to complete (I read the first 2 this year, and am almost done with the 3rd volume). It takes place during the scientific revolution of the 17th and 18th centuries when the world transitioned out of feudal rule towards a more rational and merit-based society that we would recognize as modern. It weaves together a story between fictional and non-fictional characters, including Newton, Leibniz, Hooke, Wren, royalty, and other persons-of-quality. Although the series can be slow and byzantine at times, Stephenson makes up for it with his attention to detail and the sheer amount of research and effort he put into accurately capturing the time period and bringing the story to life. Even just having the audacity to put yourself in Newton’s head to speak from his perspective, much less to do so convincingly, makes the series worth the effort.
Good Strategy, Bad Strategy
by Richard P. Rumelt
Strategy is a fuzzy concept, but Rumelt makes it concrete and approachable with many examples of good and bad strategy. Read my full notes here. Highly recommended.
Bird by Bird: Some Instructions on Writing and Life
by Anne Lamott
A great little meditation on the writing process (and life!), sprinkled with useful tips and tricks throughout.
Creative Selection: Inside Apple’s design process
by Ken Kocienda
Ken Kocienda was a software engineer during the “golden age of Steve Jobs,” and provides a fascinating insight into the company’s design process. I’m still chewing on what I read (and hope to publish more thoughts soon), but it’s striking how different it is from any process I’ve ever seen at any company, and different from best practices written about in books. It’s basically all built around Steve Jobs’ exacting taste, with designers and developers demoing their work to Steve with the hope of earning his approval. Very difficult to replicate, but the results speak for themselves.
Ogilvy on Advertising
by David Ogilvy
I hadn’t read much about advertising before, but Ogilvy’s book on the subject is great. It’s full of practical advice on how to write compelling headlines and ads that sell. Read my notes here.
Full List of Books Read
Story: Substance, Structure, Style, and the Principles of Screenwriting by Robert McKee (3/7/18)
The Color of Pixar by Tia Kratter (3/18/18)
Conversational Design by Erika Hall (3/27/18)
Quicksilver by Neal Stephenson (4/3/18)
Handstyle Lettering published and edited by Victionary (4/24/18)
Bimimicry: Innovation Inspired by Nature by Janine M. Benyus (5/4/18)
Design is Storytelling by Ellen Lupton (5/11/18)
Trip by Tao Lin (5/20/18)
Good Strategy, Bad Strategy: The Difference and Why it Matters by Richard P. Rumelt (5/27/18)
Bird by Bird: Some Instructions on Writing and Life by Anne Lamott (6/10/18)
The Inmates are Running the Asylum by Alan Cooper (6/13/18)
It Chooses You by Miranda July (6/13/18)
String Theory by David Foster Wallace (6/22/18)
Invisible Cities by Italo Calvino (6/28/18)
My Dad Wrote a Porno by Jamie Morton, James Cooper, Alice Levine, and Rocky Flintstone (7/1/18)
The User Experience Team of One by Leah Buley (7/8/18)
Change by Design by Tim Brown (9/3/18)
Darkness at Noon by Arthur Koestler (9/16/2018)
Creative Selection: Inside Apple’s design process during the golden age of Steve Jobs by Ken Kocienda (9/20/18)
The Confusion by Neal Stephenson (9/26/18)
How to Change Your Mind by Michael Pollan (10/27/18)
Ogilvy on Advertising by David Ogilvy (11/11/18)
Draft No. 4. On the writing process by John McPhee (11/14/18)