I had the privilege of talking with Mike Rohde for this week’s On Failure interview. I’ve been a fan of Mike’s work for quite a long time, and the fact that we could chat was huge! He has done work for many different clients, from SXSW to illustrating the best-selling book, Rework and The $100 Startup. His latest project has been writing (and illustrating) his new book, The Sketchnote Handbook. He had some great experiences and failures to share, and I hope you get as much out of this talk as I did.
No problem, I hope that I’ve got something of value to add. I’ve been thinking about it ever since you tweeted about it, and it reminded me to think about failure. I was wondering “what could I talk about?” but I think one of the interesting things about failure is you tend to erase it from your memory. I don’t know if I always do, but I seem to forget my failures more than I remember them.
I think that tendency to erase bad memories may be part of it. In the end I was able to think of a few good failures that were instructive in my career that may be able to help others.
It’s shipping to booksellers now, which is very exciting! On Friday I received the very first copy of the book and just yesterday I received two boxes of the book for the launch party this week Thursday. The book looks great! I can’t wait for buyers to feel it in their hands.
The PDF has been available for a few weeks now, and the reception to the book so far has been very positive. Readers really like both the look and feel as well as the teachings inside.
But there were certainly challenges right up to the end of my print production work. After the final files went to press, we found several errors and fixed them, but it was stressful right to the end.
Yes, it can be intense. Working in the web it can be easy to forget how final print work is.
I currently live in Milwaukee, Wisconsin. I work at a company called Gomoll Research + Design, a user-centered design firm. They’ve been in business for more than 20 years doing this work, and the owners are Tom and Kate Gomoll, a husband and wife team. They both worked at Apple in the 90s, pre-Steve Jobs, so they have great experience.
I’ve been at Gomoll for about 2 ½ years, and the kind of work we do is user-centered design, which means we research how users actually interact with software and then apply that research data to our structural and visual design work. It can be software of all different kinds: web apps, native apps — we’ve even worked with embedded software and hardware devices.
Lately it’s primarily been applications that have web and mobile components, like a web client, iPad client and iPhone client that all pull from the same central database. Most of the tools we work on are existing products that development teams have built doing the best they can with limited UX and UI knowledge. The tools sometimes have crazy menus, things in strange places.
The projects we are strongest in focus on user research to inform our design work. We have users of the software come in (or we go there) and we observe them using the tool. We’ll do interviews, but observations are most helpful because users don’t always tell you the truth about what they do — what they actually do always tells you the truth.
Our team tests in controlled settings, observing users to find out what things they’re struggling with, the pain points, along with the things that work well. From that data, we produce a report we share with the client, then we determine the design solution.
My role in that process is primarily as a visual or interface designer, although I’m quite fascinated with the scientific approach to user research. I’ve been involved in projects where I’ve done wireframe work, and have been on site for user tests. It’s fascinating to watch people and see how they actually react to software.
You find yourself thinking “Oh, just go down there and push that button” but users often don’t think the way you want or expect them to do. They have their own way of getting around. That’s one of the main reasons I wanted to join Gomoll — to learn the scientific side of design research, bringing my 20-plus years of print and web design to user-interface design.
That’s what I do during the day. I love it, It’s a great company! The people are friendly and smart, and the owners are great. They encourage independence and entrepreneurship in us and that makes working for the company fun, challenging and interesting.
I’ve realized that I have been fascinated with user-centered design and software applications for a really long time, all the way back to the Mac. I’ve been aware of how Macintosh software solved problems of usability, even though I didn’t understand what that meant at the time. I was a also huge proponent of the Palm Pilot and Palm devices back in the 90s and early 2000s.
In fact, for 3-4 years I ran a popular Palm website called The Palm Tipsheet. It was a monthly email newsletter (palmtipsheet.org). Each month I wrote highlights of Palm-related news, had an interview with an international Palm user, and wrote one practical article about how to use your Palm Pilot more effectively. There were often guest writers as well.
Running The Palm Tipsheet taught me a lot about writing, editing, promotion, hard work and many other skills that have become incredibly useful through the years. Turns out I’ve always been fascinated with user experience.
Palm, the company, was fanatical about reducing tap counts in their user interface. I was fascinated at how that company solved problems using very limited hardware and software. It was a small device, black and white, only 160×160 pixels, with only a little memory, but there were some amazing software tools that came from that platform. I loved how limitations were turned into product strengths. I’ve always found that approach fascinating.
Using and writing about Palm devices made me more aware of decisions on both hardware and software, as well as the idea doing so much with such a small, mobile device. The closest I had come before the Palm was my Powerbook Duo 230, the first computer I’d ever bought in the early 90s. It was pretty portable for its time — but having a pocket-size Palm device that could do a lot of the things my Powerbook Duo could was mind-blowing.
I’ve always been fascinated by small. mobile computers, so it was a natural draw for me to come back to making user interfaces, using my sense of how things should work in a mobile device.
The things that fascinate me about design are solving tough problems. I like creating solutions to challenges with limited options. You may only have a certain screen resolution, or a brand guideline that says you can only use these few colors and limitations on how you can use the logomark. Many of the apps we design are web apps, so you can’t go crazy with things you might be able to do in print design or even with a native application.
Constraints get me excited. Opportunities to work on projects you typically wouldn’t think of as being exciting do too are exciting for me. Many of the projects we do for the health industry, and might be tools for managing less glamorous but critical activities. There’s so much information in the health industry that technicians, physicians and nurses need to manage and often the tools are just terrible for those users to deal with.
I think there’s a such huge opportunity to make software for those users even incrementally better just by applying aesthetic and functional treatments based on user research. I’m excited about creating attractive, functional and simple design solutions. I like simple solutions, as simple as I can manage, so I tend to take things away from the design rather than add things. That’s one of my ideals — trying to be creative with the limitations presented to me.
I’m also fascinated with logo and icon design, for many of the same reasons. You have tough limitations. With a logo, you want something that can be reproduced in the simplest way possible. How do I make this attractive but still fax-able? Will it still look good and capture the essence of the company? That’s the same challenge with icons. You have limited space, and at some point it’s going to be on someone’s desktop and it still has to work well.
It’s invigorating to be able to solve problems when I take on a project. I try to look at it as a fun challenge, something to solve. I enjoy knowing the things I’m designing are helping someone down the line get their job done in a better way. That’s really satisfying. I don’t care so much about just designing beautiful things to win design awards — I am more interested in making simple, functional and effective designs that make people’s lives better or easier.
The illustration work I do still follows those same ideals. When I did illustrations for REWORK, one of my goals was to make sure that the message of each essay Jason and David wrote was being amplified. I didn’t want to say “Here’s an essay, and here’s an illustration and they’re sort of related” I wanted the illustration and essay to amplify each other. That way, when you see an illustration in REWORK, you think of the essay’s message, and when you read the essay, you think of the illustration.
I’m actually really excited about it long-term. They take a different approach to employment. We’re full time employees but they’re also very flexible, so I can work from home as often as I need to. They have an office for us, and provide all of the tools we need. I like going into the office, because I have colleagues I enjoy working with and we’re able to talk and go to lunch.
What’s fascinating about how they’ve structured the company is this: we’re employees with health insurance and a 401k, but rather than paying us a monthly salary we get percentage of projects we work on. There’s a set percentage that they take and a set percentage that we take based on the work we do.
For instance if I do all the work on a project, I take the full percentage for an employee and they take the full percentage for the company (which covers overhead, etc.) If two of us work on a project, then at some point we sit down and negotiate how much work we did and figure out the percentages. Projects are divided up accordingly.
The advantage of that system is that it frees me up to do other projects if I wish. In fact, when I first interviewed the owners wanted to make sure I had projects going on. They want people that are entrepreneurially minded, which is great. Now 2 ½ years have gone by. Everyone there is a true professional. You’ve come to the level where you’re expected to solve problems on your own and initiate things and for that you’re given a great amount of freedom and flexibility.
There’s a high expectation to go along with the freedom. It’s not like “well, my boss hasn’t given me anything to do so I’ll sit in my cubicle until someone tells me what to do”, you’ve got to figure out what to do. If something goes wrong you have to fix it. There’s a lot of trust in us to be independent, to make smart decisions. It’s a fascinating structure that works for me.
Two stories that popped into my head, one from a long time ago and one from not so long ago. I think I tend to block out failures. I try to learn from them at the time but I also try not to dwell on them in a negative sense. Often if you dwell too much on failure there’s a higher chance something will actually go wrong because you’re obsessing on it. You have to really focus on the good things you can learn rather than the negative aspects. Getting in a negative mindset can mean you’re more likely to repeat your mistake.
The first story of failure one is an old one, from my print designer days, long eons ago in time. We had a booklet project right about the same time as NAFTA. We did the design, thought everything was great and sent it off to press, and it ran.
One of the design features on it were three flags of the US, Canada, and Mexico. As it turned out, I had inadvertently flipped the Mexican flag upside down. I didn’t know that flag very well at the time, so I missed it being flipped.
This is of course quite offensive for a Mexican — like an American seeing the stars and stripes upside down. It had a meaning that as a young designer I didn’t fully understand. The booklet ended up having to be re-run — we paid for those costs and I got yelled at for it, and for good reason. I learned from that failure to be more aware, to double check my work and to better understand the significance of the symbols I design with.
Not long after that, I met a friend from Germany here in MIlwaukee. He invited me over to Germany to tour the country with him, so I went over to the black forest and stayed with his family for two weeks. We went to Switzerland and briefly through Austria, we went through the western side of Germany, up to Berlin, Dresden and back. I had this really amazing first experience of Europe and it made me much more sensitive to other cultures — what they think, what their perspectives are and how they are often quite different than mine.
I think those things are always tied together; me being a young designer not paying attention to a flag and I really should have. Now I’m sensitive to that. For instance, the book I wrote (The Sketchnote Handbook) is available in other countries, the contributors of the book are a mix of both men and women from all over the world. That’s important to me. So my flag failure was a hard lesson, but it led me to understand why a flag could be that important.
The second story of failure is from a couple of years ago. I worked at another firm for about ten years from home, and we were all about web design. At some point in the process, our client base shifted a little bit, and I had to start selling myself to get projects.
I had experience as a logo designer in my previous job, doing identities and branding as a print designer, so we thought that the software companies might need design work. Maybe we could become a software firm’s secret weapon. As it turned out, it was a great idea and I was able to get lots of work designing logos for companies. Many of those logos still exist today, so it was a good experience helping these companies designing their identities and first sites to compete with larger companies.
So I’d built this reputation as a logo/identity designer for tech companies, because as a geek-minded designer I could understand what other geeks were thinking and translate that into an identity. I was pretty busy, and I got a project in from a client in the UK.
I started producing ideas, but the client seemed to dislike everything I did. I was failing at producing what he wanted. I was also very busy at the time, trying to do too much. I was finding the clients, convincing them to sign on with us, invoicing them, doing the design work, doing the web work, invoicing them at the end, and promoting the work we did. I wasn’t turning down projects and was taking everything I could get. Looking back now the prices I was charging were too low, but at the time I was just trying to get the business going.
The client didn’t seem to be syncing with what I was telling him. Later I learned that I hadn’t sufficiently set expectations and was too busy to properly solve the problem. I had 4 or 5 logo projects happening at the same time, and ended up delivering this work later than expected.
One of the things I learned was to clearly set expectations and deadlines. There really wasn’t any of that set when we started, which meant his expectation was sooner rather than later and I was overloaded trying to juggle too many projects. In the end, we finished one logo out of two we were going to do, and then he cancelled the project. I was really bummed out at the time, and hurt that I hadn’t delivered.
I felt that I was really good at logo design, and had a good track record, so it was hard to take. I observed after he cancelled the project, that one of the challenges I faced was taking on too many projects and asking myself what was the best value I could offer to customers.
At the time I was doing everything, and it came to me that I just couldn’t keep that up. I realized my value was understanding what the client needed, creating a brief and then sketching concepts, and in the case of websites hiring someone who’s an expert at front-end development.
I started developing relationships with other designers to do some production work on logos and to do front-end work on websites so I could keep myself focused on my areas of value. It was painful to have someone cancel a project. It shocked me into seeing I had booked too much work and needed to change my approach for the better.
That’s an interesting question. Safeguards can be helpful, but not a silver bullet. By that I mean you can build all the safeguards you want but you’ll probably fail in a new, unknown areas. It’s better to figure out the principles of why you’ve failed, because If you understand the why of your failure, you have a better chance of catching and preventing future failures in new, unknown areas.
For example, I’ve found it helpful to communicate either good or bad news with my clients as soon as I know. Especially if I have to say “Hey, I’m not going to have this done for the deadline, and I know it right now. Let’s figure out what we can do together.” I’d rather let the client know and get news on the table so we can solve the problem together.
To be the initiator in your communications is important. I’ve tried to follow that principle and it really helps. Of course there are times where I mess it up, and when I do I’m reminded that I should have followed my own rule.
This actually happened on The Sketchnote Handbook project. My original deadline for the book was September 1st. In the middle of the project I started looking ahead and it was pretty clear there was a ton of work to do, but I just kept moving.
However, in early August, near the middle of the inking stage, I looked ahead at what I had left to do and realized there was a good chance I wasn’t going to make the September 1st deadline. I had two choices: say nothing and work as hard as I could to hit the deadline or alert my editor and figure out how to solve the potential problem.
While it was tempting to just work like crazy to meet the deadline, I chose the second option — to communicate with my editor early to solve the problem while we could still maneuver. I told her I wasn’t confident about meeting the original deadline and asked what options there were. Should I file for an extension?
As it turned out, my editor had built extra time into the schedule. The Sketchnote Handbook project was unusual, because not only was I was writing the book but I was also illustrating and designing the entire book for final print production. Those unknown variables guided her to add time to the schedule — an example of using her experience to help prevent failure.
It was a good move to reach out to her to talk about it. Together, we figured out a more realistic deadline. My early, honest communication helped build trust, since they weren’t in the dark on the project and had time to maneuver and solve the problem. Of course my constant communication from the very start of the project also built trust before that stressful moment.
There’s this tendency for us to believe that if we don’t say anything about a potential problem that we can just figure it out and solve it in time, but I’ve learned from years of experience that doesn’t always work out so well.
The second principle I learned from is to come to the table with a solution even if there is a failure, not just delivering the bad news. If you are going to miss a deadline, present when you can deliver it, or part of it, so that the client doesn’t feel stressed out. Don’t drop the ball on them — take the responsibility and propose a solution.
Right, they want someone to be able to take charge and make a decision. That’s why they hired you. You’re the professional and you should know what’s going on, and if you don’t know you can come to them honestly and say “I don’t know the solution, but we can work together to solve it. Let’s talk about options we have.” I think that honest dialogue goes a long way to building a trusting relationship and helps in solving the problem.
A big one — admit the failure. To deny the failure or blame it on someone else isn’t good. Until you admit you’ve done something wrong, you can’t figure out the solution. It’s important to say that, and the next part of it is sit down and evaluate what went wrong and how it happened and how you can learn from it. Use it as a way to deconstruct the mistake and turn it into a learning experience. Not in a negative way, because I think it’s easy to beat yourself up with how you failed. There’s no purpose in that negativity.
The failure is done, there’s nothing you can do about it. Do whatever you can to right the situation, even if that means eating some costs. In the long run, it’s going to make you a more honest and ethical designer. Even if the client is unhappy with the situation, being honest with them lets them trust you at least for your honesty. I’m sure they’ve made mistakes before too.
I’m glad I could help out, I’m really all about that. The whole reason I did The Sketchnote Handbook was to help people solve the problem of note taking. Sketchnoting solved a problem for me, and I felt there had to be others out there like me who have the same problem. The only reasonable solution is to try to teach and share this. The same thing goes for design lessons.
I was just thinking about this: If I was to recommend a book on the subject it would be Mike Monteiro’s Design is a Job. It’s outrageously cheap and good, It can be read in probably one sitting, but it’s a great book encouraging professionalism and how to treat clients.
I think it’s especially helpful for young designers, as they may not have many role models to follow and learn from. If you’re a designer, you’re lucky to get into a design agency or company design department with a good art director who can teach you, but a lot of designers don’t have that. To have community leaders like Mike establishing how things should be done is great.
I think as an older designer who’s seen a lot, it’s my job to be mentoring and providing feedback and guidance for young designers coming up. It would be easy to sit back and be cranky and complain about all these young designers “taking jobs” or whatever, but the challenge for me is how can I help them? They’re going to have to deal with this business when I’m gone or doing other things. I need to pass knowledge along to the next generation.
Yes, I think there are a lot of helpful resources out there, like Dribbble and so on, where designers can get encouragement. I think the next step is how can we provide a better way for constructive criticism for young designers in a world where many responses are just “Oh, that’s awesome!” Nobody wants to put their stuff out in public and get shredded, so what is the solution to that? Is there a place where young designers and older designers can come together and trust each other, and it’s done in an encouraging way so there’s learning that comes from it?
How can we foster a little more criticism, not to rip on anyone but to help? If you look at my book project, I could have seen my editors as really cramping my style, because they were always asking me “do you really want to say this?” or “you spelled this wrong” and there were constant challenges. My attitude always was realizing the editors really want to make this book better, and if I wanted the book to get better I needed to listen to them, and take every challenge as an opportunity. That really made the book better.
I want to be known as a designer who can be called when other designers get in a jam, saying “Mike, I got this situation, here’s what’s going down. What should I do?” Just having someone to talk to is a huge help. If you’re all alone and you don’t know who to talk to — that’s terrible. You should have other people you can count on and ask questions, sort of a jedi council of people to help make decisions.
Glad I can help, I appreciate the opportunity to share my mind, Ben!