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)
Design doesn’t own the customer experience. A great customer experience is the emergent outcome of the contributions of every department.
Design is not the center of the universe. Design is one function of many at an organization.
Other departments have more customer contact than you. Listen to them.
Don’t hand your work down from on high and expect everyone to worship its genius. You need to bring people along for the ride so that they see how you got to your solution, and can get there themselves.
Everyone can improve the customer’s experience, not just designers. Foster an environment where everyone applies a user-centered mindset to their work.
There’s no perfect, one-size-fits-all design process. Skilled designers have a variety of tools in their tool belt, and know when to use each one.
Done is better than perfect.
No design is perfect. Always be iterating.
Don’t fall in love with your designs. Be willing to kill your darlings.
You should always feel a little uncomfortable showing your work to peers. If you don’t, you’ve waited too long.
The only thing that matters to customers is what ships. Not your prototypes, wireframes, user journeys, or any other artifact of the design process.
The only true measure of your design’s success is the response from customers.
Stay curious. Regularly seek out new ideas, experiences, and perspectives.
Stay humble. You don’t know what’s best just because the word “designer” is in your title.
Don’t hide behind jargon and the cloak of the “creative.”
Great design is rooted in empathy. Empathy not just for the end user, but also for your coworkers, company, and society.
Having empathy for your customers means actually talking to them.
Don’t automatically ignore someone’s feedback because they’re more junior than you, or don’t have “designer” in their title. Don’t automatically listen to someone’s feedback because they’re more senior than you.
Design needs to be aligned to the needs of the business, and deliver measurable business value. Don’t design for design’s sake.