10 UXDERS, 10 QUESTIONS, 10 WEEKS

Week 8, Learning from failure: 10 UXDers, 10 questions, 10 weeks

Allison Wolfe

Published in

PatternFly

14 min readNov 24, 2021

The title card for this week’s question, “Tell a story about a product you worked on, and what you learned from it.” featuring headshots of all 10 contributors.

When we think about failure, we often think about it as the opposite of success. But what if we reframed failure as part of the road to accomplishment? This week, we asked each of our UX experts about past project fumbles: what happened and, most importantly, what they learned from it.

Tell a story about a failed product you worked on. What did you learn from it?

Wes: Research Operations Coordinator

One of the products I worked on during my time at a previous company was a hybrid tablet and laptop computer, sort of like a Microsoft Surface, where you could attach and detach a keyboard. There was a long development process, it was a brand new product, and a lot of testing went into it. We had a lot of questions for testing, but we only had the budget to do one big research effort somewhat late into the development process, after 90-something percent of the design was already finished and unchangeable. We got a lot of feedback on certain things, one of which was the pen that went with it that allowed you to write on the screen. One thing that my team and myself championed was you have to have a place where to put the pen on the device, and there was no place to put it. That was one of the top comments from this research and it was like, “Okay, what can we actually do for this?” We ended up having a compromised solution, which was putting the pen holder into one of the USB ports — and that would have a little loop for your pen. It wasn’t a great band-aid because users wouldn’t have access to that port. We got hammered for that in the reviews.

In summary, my team brought up the concern and proposed many different solutions. But given the timeline and cost, the decision was not to take our proposed route. And then several months before launch, we finally were able to do research, and it confirmed our concern. It was research too late, and for the second and third generation, they improved. I had left at that point.

The lesson there was to do research as early as you can. I know that’s not always an option. We brought the issues up in every single decision meeting and it got to the point where they almost shut us down before we started talking. I think we could have been more strong-headed with that. Early research could have helped, and led to understanding the solution better. Earlier in the process, you have more opportunities to make changes without severely impacting the timeline or cost.

Beau: Principal User Experience Designer

About 15 years ago, I helped to integrate a new platform that we would use for a website. It was a company that sold contemporary art. Contemporary art is very hard to categorize, so if you think of shirts: You have small, medium, large. But with contemporary art, you have one painting so it is like an inventory of one. We tried to create a website system that had an inventory in the backend and we actually used a really cutting-edge tool. I was sort of doing user interaction design and information architecture, and a little bit of coding. I don’t think I was listening to the team — the tool we picked was something myself and the account manager really wanted to use. It was something to turn art into, put it into a database, and sort it — sort of unconventional. We ended up pretty much getting half way through the implementation. It was quite expensive and they decided it was too complicated for the product. So I think what I learned was that you really need to vet big ideas and big changes with the whole team. You can’t just pick your echo chamber and vet within the echochamber, the people who are going to agree with you. You’ve got to have the hard conversations with the team and figure out if what you’re proposing will actually work.

We ended up scrapping the tool and going with something that wasn’t as cutting edge and couldn’t do everything that this account manager wanted. He wanted to do a query to see all the art that fit this criteria, but it was almost asking for more than was realistic. For decisions like that, you’ve got to get the team on board. You can’t forge forward because when you forge forward, you end up in that situation where three quarters into the project, you don’t get buy-in and you end up scrapping it.

In the end, I would have chosen a different tool if I had asked the people who didn’t agree with us. So I think I made a mistake. I just didn’t get them on board. Unless you get everyone’s input, everyone’s requirements, and then you figure out a direction, you’re bound to run into what I did with that product.

At Red Hat, I’m working on one of the experience projects where we’re trying to combine and work across five teams to create a journey map and work on a journey level. It’s incredibly difficult because some of the teams want to do it one way and some teams want to do it the other way, and every time we make three steps forward, we end up two steps back. This project focuses on developer tooling, so any products a developer would use in their day. And what’s interesting about developer tooling products, is that we have a lot of smaller ones that developers group together. So this journey map in particular lends itself to the idea of seeing how they stitch products together and making sure that amounts to a good experience. Each one is owned by a different team and a different group and a different organization, so trying to get everyone on board with an approach is challenging. We’re moving slowly, and I’m trying not to forge forward until we have some kind of consensus.

Roxanne: Associate Manager, User Experience Design

I have a couple examples of different projects that were not successful. I’ll start with a simpler one.

At one point in my career I was working on HTML emails, both the design and development. The stakeholders knew what the click-through rate on these emails were, and it was abysmal. The focus was on saturation not on creating enticing content. This particular art director had me put in an incredible amount of effort to swap out one photo: He had me change it more than 11 times. That experience solidified my feeling that acknowledging the business impact of what you’re working on is critical to success. Spending many hours iterating on an email that’s never going to get clicked on was not good business. That’s not valuable to the business and it wasn’t a growth opportunity for me. Settling for good enough is, sometimes, an okay strategy. Aiming for perfection can be harmful.

I was just at the Philadelphia Museum of Art, and they have an amazing collection. Picasso, Dali, Monet… just to name a few. Looking at those, did we think that they thought that their own art was perfection? I don’t know. Would we have even noticed a small stroke difference? Probably not. I think perfection can be dangerous; it can lead to stagnation and could lead to not getting something done.

My second example was when I was working at a company that was creating a platform for matching people to careers, there’s a lot of them out there right now. That project wasn’t particularly successful. I don’t necessarily think it was because of the design. I think that what I learned from that experience is that leadership matters. When you have teams of people and leadership is perhaps ineffective, it doesn’t always matter how great the thing is. It can only be as great as the team is as a whole. If you have leadership that’s dragging it down, it’s sort of destined for a bit of failure. But I still had a lot of fun, and I learned a lot design-wise.

Alan: Senior Director, User Experience Design

For this question, I’ll go back to Bose. A really innovative product I worked on and I actually have a patent on was a wireless remote control for an at-home music system. Basically, there was no head unit on it. This was a radio frequency-based system, so you could be in another room and change the music. It was also for multi-room usage in your house; you could carry a remote with you and that was your system.

The big question for us was how to hide the music system. Bose was known for having really small speakers that could play high-quality sound at high volumes. All you would see of this whole system were small speakers in a room. Of course, there was a little box that you would plug into, but it sat behind the sofa. You didn’t even know it was there and it was pretty small. There was a big bass box as well, which was the biggest thing. That system was very difficult to design and engineer at the time, at a reasonable cost. Even though the system ended up being very usable, its price point was significantly higher than a typical Bose product — and Bose products are known for being typically pricey to begin with. So this product ultimately failed because it wasn’t economically feasible. Believe me, we took all of the standard cost out of it, but when you’re working on hardware, you have a lot of cost constraints. I think we engineered and designed the sound system the best way we could. It was just too pricey.

Every quarter, we had to present our projects to Dr. Bose. The finance team had to present, the designers, the engineers. We all had to present the status of our projects. And this particular presentation was a review where Dr. Bose could have said, “We’re not going to keep exploring this because it’s moving too slowly or the cost is too high.” In this case, it would have paid to look hard at this product’s costs and whether it could really be successful in the market that Bose was in. Even though the technology was great, it probably should have been stopped. So maybe we could have learned from that technology and used it on another product in the future. But to my knowledge, the majority of that product’s technology didn’t carry forward to another product because of Bluetooth and other progressions. There really was no need to have a proprietary solution anymore.

Matt: Principal Interaction Designer

I think that most of the time when projects fail, it’s because they weren’t well-supported by their organization. Either financially, by management, or they weren’t given the appropriate resources. Most of the time when I’ve worked on projects that failed, it may not have been obvious upfront, but down the line you’d begin to realize maybe it’s better off not continuing. And then you sort of wonder why management is even funding it, because they clearly don’t want to make the investment for the project to actually succeed.

And sometimes there’s reasons why they won’t cancel the project, because politically we have to keep this project going. Or we think maybe down the road, this will be important. But it’s always frustrating for the people working on the project. In those situations, people who can get off of the project always try to find ways to do so, which just makes things worse. Sometimes it’s difficult to understand how a project fits into the bigger picture of the business, and we don’t always have control over what we get assigned to work on. So usually when projects fail, it’s because of a management problem.

Joe: Principal UX Developer

At a previous company, there was a storage management project that was developed, before we had a UX team, and developers designed the UI. The end result looked like the file system on Mac or Windows. Everything was rendered under a root node and as a user you would expand nodes beneath with a logical tree eventually forming. For example, when you clicked on the storage system, the ports would expand, then the disks, etc. It was neither scalable, intuitive, nor performant.

We replaced that design with a more intuitive version, but it was in production for a time. While it may have worked for smaller systems, it definitely did not scale up to allow management of the larger storage systems that were being developed alongside this project. It was a simple concept to use a file manager as a base since users are familiar with that tool, but maybe too simple for such a complex task.

Some user research would have helped us out for sure. I think we would have benefitted from having the knowledge that the number and count of what we were trying to display would increase by a significant factor.

I learned to never use a file manager as the bones of a management system :). Plan for the future, plan bigger. When dealing with management consoles, the system being managed is always going to scale up, so keep that in mind. If you’re designing a management system and you see that you are currently operating on x items, just be aware that x is going to become x cubed in the near future, so design for the future.

I can’t say that I had a failed product, but I’ve had some failed designs. So I started working in a company that wasn’t really sure about their product vision because they were in very early stages. We didn’t do research; we just started designing. We assumed, “This is our user and this is what they want.” And we didn’t have really good goals tied to that. I think that’s the main reason why when I showed it to users after we finished, nobody really understood it. Nobody actually understood their needs.

The product ended up pivoting and being something completely different. We worked on something for a few months that never saw light. I think we jumped into it because the company really wanted to see results. So I think that experience taught me to do research earlier and feel comfortable saying, “There will be no results for now. I need to study because I need to learn.” Because I was kind of new, I didn’t want to say that, though. So I think that lack of research was what killed us for that design.

I think it’s important to understand that failure is a part of success. Now, I know how to do that process right, thanks to failing in the past. I know what to avoid doing again.

Marie: Interaction Designer

This is a tricky question because I haven’t had many products or projects in my UX career. But I remember when my product just really silenced, really calmed down, and basically almost didn’t exist. Nobody knew about it, because the strategy and communication between products was unclear.

I learned it’s so important to have constant communication between product managers and establish a strategy before you start because you don’t want to have a dead product. When product management and higher management don’t have a strategy, it’s impossible to run something.

Allie: Senior Interaction Designer

I worked on what is now the Global Entry machines at airports. The request for proposals was to design a fingerprint scanner that could be used by any traveler, from any culture, and with any amount of flying experience. While my design team was exploring design ideas, we learned that symbols we think would be universal, like the hand symbol, wouldn’t immediately be recognizable as a hand in other cultures. Some cultures don’t associate red and green with negative and positive actions. Navigating those challenges was difficult and educational. The solution I came up with wasn’t the winning one, and I didn’t get feedback as to why another company’s design won. However, current Global Entry machines are mostly text-based — so they didn’t wind up meeting their own goal of universality.

That product, even though it didn’t succeed, was cool because I was designing not only what was going to be on the display, but also the physical shape of it. I had a room full of cardboard and pipe cleaners to try out different shapes. Then I had engineers from the company come in and pretend to scan their hands and carry out each task. I’m not sure what I would have done differently on this project because it was only a few years into my career, and I think I did a good job for my skill level. In general, I wish I had someone on the team that was more culturally aware. I’m not even sure what kind of expert we would have brought in for that, but maybe someone who had worked on these types of global-use-case challenges before. It was eye-opening to see that this was a problem I couldn’t solve on my own. I did my best, and I didn’t win, but I still learned along the way.

Margot: Interaction Designer

I don’t feel like I’ve been working long enough to have a failed product, but I have created designs only to find out they weren’t even doable. I learned the importance of close contact and communication with your development team throughout the whole design process, not just at handoff when you think you have it figured out. Remove assumptions and keep asking questions at all steps to avoid having an unimplementable solution at the end.