10 failures for my first Oct.13
I recently learned that October 13th is the International Day for Failure. So if you are reading this today, Happy Failure Day!
I have not failed. I’ve just found 10,000 ways that won’t work.” Thomas Edison (…I think)
The concept of celebrating failure is not new. Many people advocate for failure so that you learn from it and do it differently the second time, use it as inspiration to change a company’s culture, or even to show others what path not to take. However, one thing that I noticed was that, even though I have heard some talks about failure and loved them, I have never sat down to write down my failures.
So, this is where I ended up. I will write about my most memorable failures so that I can reflect and write at the same time. So, I apologize if this is not written in the clearest & most efficient way.
- Printed 5,000 flyers with the wrong image.
After graduating from uni, I went straight to work as an intern in an ad agency. Here is where I first used design programs to create marketing materials and not art projects. You can’t imagine the number of mistakes I made… but one of them will stand out above the rest.
I was handed the task to design a new triptych pamphlet. I made a wavy design, blue and yellow, with funky typography still remember it like it was yesterday. I was using Indesign for this, and well, I forgot to re-link my images after photoshopping them. One week later, 5,000 flyers arrived at the office with the front image completely blurry. Oh no! What had I done? So much money was spent due to a simple, ignoring the warnings, mistake. My boss then called me into his office. Yes, I was in trouble. I just knew he would fire me right there and then, but to my surprise, he did not. Yes, he told me I made a big mistake, but he also told me he had made several himself and to not let it shake me. He gave me the pep-talk I needed.
I have learned 2 things from this. One, to pay attention to Indesign warnings, and second, that one of the criteria of a good manager is to be emphatic. He might have had a different speech ready, but he chose the one I needed to hear.
2. Used the wrong programs to design a website.
Back when I started designing websites, I decided Adobe Indesign and Adobe Illustrator were the right programs for me. Yes, many of you just rolled your eyes or laughed at me. But they were what I had learned to use and seemed appropriate at the time.
When I delivered my design files to the front-end developer… well let’s say they almost had a heart attack. I should have known. Every time I opened AI, the heavy design of the website would make my computer crash, but I didn’t understand why. Also, the FE-Dev did not have access to the typography I selected, exporting the images or any of the fancier things found today. This made it incredibly difficult for us to work together. Our solution back then was to design and develop separately, even though I had given her a nightmare of a file to work with. In the end, it was ok, my FE-Dev made it happen.
So what was the failure here? Was it just a bad selection of programs? No... the thing is that back then I did not respect the relationship that designers and developers have to build for the end experience to be successful. Today we work with programs that ease a lot of this communication, but still, struggle to understand the different roles in our teams and we do not share enough work or responsibility in the end experience.
3. Designed an interactive touch-screen no one wanted to touch.
One of my last assignments, before I started my master's in Interaction Design, was to design an interactive sales experience. The concept of touch screens was very new and innovative at the time.
My colleagues and I researched a lot on how to deliver this, studied the logic of the navigation, made sure hand gestures were considered, that the salesman could stand next to it or handle it from far away.. etc. The interactive sales experience was designed with lots of details, fancy graphics, proper back-end to handle the data, and even how high it would be placed on the wall. We then decided it was time to be tested with real users. People would walk into a room and we would observe how successful they would be at achieving the tasks we had asked them to perform. The day to do these tests arrived and we immediately saw the biggest issue we had missed: people did not want to touch a tv, it just felt wrong to put your fingerprints on a screen on a wall inside a fancy room.
All the work we had done so cautiously, and we missed one of the most basic things: creating a safe area for the user to play and explore. Later on, we fixed the experience by adding some guidance and animations to let people know you should use the touch-screen to explore. However, I’ll never forget the feeling of complete failure. And although we fixed the problem, this was the right push for me to study my Masters of Interaction Design. To do the research and make sure users are involved in all steps of the design.
4. Built documentation in a program only I used.
One of my first jobs with the title, UX designer, was with cars. To successfully produce such a complex product, all sorts of documentation need to exist. From design decisions, the color of an icon to complex engineering documents, all must be documented to be produced to the best quality.
In the project I worked on, we were setting the pathway for a new way of working. Involving engineering, design, and suppliers more often and from a much earlier stage. This required a new way of documenting our wireframes, visual design, and stage at which the design is. I came up with the fantastic idea to use Indesign (yes, again with my wrong choice of programs), but the team had given me a warning that no one else knew the program well and they were not comfortable with it. However, in my mind I was an InDesign master and could teach anyone how to use it, everyone would love it and love me for it. Oh boy… if I was wrong. The number of steps we had to do to document every release was insane: check image links (important, see #1), check hyperlinks, check folder structure, etc. It was so troublesome that very few of us would get the releases done without mistakes. And yet we chose not to change the process, just because we didn’t see change as a possibility.
This turned a bit into a nightmare for me because so much of the documentation was built with something I only felt comfortable with. I shouldn’t have pushed my team in a direction they had highlighted as troublesome. Secondly, we should have changed it right away when we saw the issues… not wait until it felt impossible to change. And lastly, there is nothing impossible to change, especially if that is to improve the team’s way of working for the better.
5. Designed a structure no one could navigate.
A while ago I was given the task to create the first Design System for a company that consisted of about 1000 devs and designers. I had never done such a thing before, so again, made many mistakes… even gave a Webinar on the lessons learned. So the next 3 failures listed (5,6,7) are on this specific project.
One of the first things we identified as a necessity was to have one place where to find the correct design guidelines. We had already started some sort of sorting inside our design files but decided to confirm it with fellow designers with some good old card sorting. The results that came out of this sorting reflected exactly what was going in the company at the time… lots of silos, missing connections between components, and above all that our sorting of elements was very off. We then decided to not address this problem but instead do a new grouping that made sense to us. Of course, these 5 files we chose to design elements into became a big obstacle for designers to adopt our design system. They had to learn to navigate, never knew where things were, and ended up creating more work for us.
Pff… so many lessons here. One, act on your research… that's why you did it in the first place. Second, don’t assume you know best. Third, if the problem is too big to understand then you need to break it down into smaller pieces to handle. Fourth, make sure you tackle the right problem.
6. Did not get top management on board for the project.
When we started our Design System project. We put a lot of effort into getting the teams, devs and designers onboarded to the design system. And while that was creating a slow adoption rate, it was working… little by little each team was approaching us for different things.
The rate at we which we were going was too slow. Although we had tried to get top management on board, we had failed to communicate what our team needed to succeed. The rate at which we were getting feedback and people needing our support was growing, yet we were only the first 3.5 people that had started the project (half time for me). What ended up happening is that top management hired someone else to take care of it, to speed up the process. Not the top management that we had spoken to, but the top management above that layer who had just seen how the company needed a face-lift, something to unify the teams and drive better collaboration. Of course, this produced some adversity from the designers and developers.
Our project ended up being consumed by an external agency. And it helped them with the foundation of it but they also made an insane amount of changes that made some of our components unusable. So the lesson here is to make sure you go up the chain with your projects. Don’t be shy to speak to the CEO if needed, you get the people you need for what you need to get done. And give them feedback on what happens and how the teams feel.
7. Beta tested… just wrong.
Beta tests exist to try out the experiences we have designed before we go full out to the public. For the design system, it seemed appropriate to do some alpha testing by ourselves first, then some beta testing with one of the teams to see what were the major obstacles.
We decided to beta test with a team that seemed interested and eager to try out the design system. However, one thing that we didn’t do is research who they were, what way of working they had, or even why they were eager to adopt the design system. As it turned out: the designers were eager but not the developers, the developers were coding in a completely different language than our components and the developers were part of an external team. External teams were not our primary or even secondary target group. So how did the test go? Horrible. The team adopted the colors and typography but refused to adopt anything else that could produce more work. Also, the designers couldn’t agree on what design to pick so no decisions were made. Therefore, the feedback we got was very limited and only applicable to a small part of who we recognized as our user group.
Now, I have learned that to do beta testing, you need to pick your audience carefully. You need to be specific on what tasks/scenarios you want users to go through and give feedback on. Above all, you need to know the users’ current journey, with the struggles to better understand if the desired experience was achieved with the new service you provided.
8. Ignored local flavors in favor of global simplicity.
One of my past projects was to be the how-to-girl. I was leading the design for Customer Support content for a large e-commerce site. This meant we wanted to globalize support content to better guide specific countries on how to write content and be more SEO-friendly.
We started this project by digesting some interviews and card sorting Germany had done and also understanding how the business wanted to portray their services. After that, we created a modular structure that could help countries prioritize different information according to their situation. We decided to include 2 more countries in the work to get a better global understanding, however, we never put these people in the room to talk together. We were the ones holding the knowledge, processing, and delivering packages that they could not relate to. The business input we got allowed for even less freedom, and that was not taking in well by countries' content designers. So it happened, when we released our structure… no one wanted to use it the way it was intended, they all had local flavors they needed to add.
Looking back at this project I realize that the amount of designing structure should have been minimum. What should have been the focus, especially at the beginning was understanding the countries we spoke to, getting them in a room together, do workshops, explore content opportunities and figure out how a local flavor layer can be added.
9. Said yes to too many things.
In all the projects I have worked in I have taken the role of the octopus. That person that has their hand/eyes on everything and is balancing multiple plates.
I used to think that this was the only way a UX designer could succeed in changing organizations. Showing them through various areas of a project how to become more human-driven. However, the other side of it (which I’m currently in), is taking too much. So many different things to do and have my arm in have made me do some simple mistakes: forgetting meetings, designing without the whole flow in mind, even making decisions quicker than they should have been made. So the lesson here is to learn to say No in a balanced way. If you say no too often, people grow tired of asking you for help. If you say yes too often, you will need to transform from an octopus to a centipede and that's just not sustainable.
10. Aimed too high, making it impossible for me to write.
One of my latest ambitions is to be more outspoken with my knowledge, feelings, and creativity. I wanted to write, give presentations, teach others and do all other sorts of “public” things but constantly failed at giving it the appropriate time.
It’s common that if you want to get started with something new, you just have to break it down into smaller pieces. That is the behavioral experiment my company Inuse is promoting us to do this week. But, when it comes to sharing knowledge, I kinda forget about this. So… why am I failing at this? As I am writing here, I have 3 open tabs with 3 other half-written articles and 2 PowerPoint presentations semi-done. I had set my goal of writing one article per week. This did not happen. I only wrote one article and burned myself out with the many ideas of the next articles.
I recently read that this behavior is part of the creative process. Having multiple projects at once allows for your brain to rest and change contexts to keep it motivated (apparently this was Einstein's process). I understand that some of the projects I have going on need that time and change but some of it is also just the amount of pressure I put on myself. The procrastination of the other articles led to this article. So it is important to differentiate when you create new projects due to a much-needed change or when you are setting yourself up for failure by aiming too high instead of just starting small.
The perfect example is this post. I started with the ambition of 13 failures to share, but I failed to make them short and I failed to write 13 to make it in time to release today. I had to down scope.
💭 Concluding thoughts
Uff… that was long.
It’s fun to see that my failures changed as I grew up as a designer. From being very practical and affecting my deliveries to spreading across different parts of the organization. All of these failures, big or small, have produced a ripple effect in the way I do things today. I can see each one and connect certain behaviors to them, also recap so I don’t repeat some of them 😱, so writing about them was excellent for my evolution. Also, it’s extremely nerve-wracking and I feel exposed by publishing this. Somehow I feel like you will judge me and think I’m not the smartest designer for doing some of these mistakes…
On the other hand, writing this felt a bit sensitive like if I was breaking some of the trust/secrecy between my teams and me. By no means do I mean to offend anyone. Instead, the things I have selected here have shaped me as a designer and as a person, to be more humble, ask more questions, understand better and be less scared of failing. I have nothing but gratitude to the teams that have allowed for this, creating a space where it’s ok to fail and where trust is not hurt but fostered.
Thanks for reflecting with me on my failures. How about you? Why don’t you try to make a list of your own?
