You Can't Fix the UX Without Fixing Everything

8 Things I've learned in my first year as a Product Director in a small startup.

tl;dr just read the big text, if you want the details please read on…

About a year ago I joined a small startup as a Sr. UX/UI Designer and after a few short months I found myself in front of my boss who was asking if I wanted the role of Product Director. To be honest, at first I said no.

While our start-up was small, the role was not. It required managing all aspects of the product: Direction, bug documentation and management of 7 engineers (5 on-site, 2 remote). I had some experience in management but nothing that would have prepared me for this. I never managed and planned work for a large and highly technical team. And If that wasn't enough, I would be inheriting a product that was going in the wrong direction, had a messy code base, a bad User Experience, and more bugs than an Amazon rainforest. Taking all this into account, I decided to decline so that I could focus on fixing the lacking User Experience.

Lesson 1: You can't fix the User Experience without fixing everything.

We tried having someone else in charge for a short while and I soon realized that I had taken the coward’s way out. If I truly wanted to fix the User Experience, I would have to fix everything. Trying to make an interaction easier to use is useless if the page load takes too long and the information is incorrect. You can have beautiful charts that graph the data in just the right ways, but if the user doesn't care about that data or that feature, then there is no UX.

So I met with my boss again and jumped in. I wish I could have said yes the first time and charged in fearlessly to grow and be challenged but that wouldn't be honest. If I told you the lie I told myself, that I just wasn't interested in leading, and that I wasn't qualified anyway, that wouldn't be honest either. The truth is that it took some courage and I'm glad I had a second opportunity.

Lesson 2: Do things that scare you.

So I did it. When I say I did it, I mean that I barely got by and wasted a lot of time trying to do everything. I quickly learned that I had no idea how to manage other people’s time effectively, and that I didn't really understand agile development. I noticed that when you are a bad leader you have a tendency to try and hide it by pushing everyone into “your way”.

Lesson 3: Pride kills, ask for help.

So instead, I laid down my pride and asked for help. I talked to our lead engineer, I talked to the CEO of the contracting firm, I read a lot, and made sure to not say “Ya I got it” unless I really did understand. Many times that was embarrassing but I learned those embarrassing times got farther apart, and things started to run more smoothly.

Once I got the basic process out of the way, the smaller ones started to pile up. I went from doing design 100% of the time to 0%. My entire days were taken up with meetings, planning, checking up, double checking, maintaining documents, etc. I spent my whole day managing my team but there was no time to manage the product. I knew something had to change but when you are scrambling to keep your head above water it’s hard to make changes to process.

Lesson 4: If you're too busy to fix your process, you're moving backwards.

I soon found myself moving the other direction, with more work than I could do in an 8 hour day. So I hit the brakes and started to solve our process. I cut meetings down. I delegated tasks. I found technologies and plugged them in. I got strict and reminded people to stay within our process. It wasn't easy but soon I saw the fruits of my labor. I finally had time to breathe and I learned that with free time to think comes even better processes.

Lesson 5: Don't be afraid of employees with free time. They will always reinvest it.

I took that learning and applied it to my team. They had been overloaded for months, so I put my foot down with my boss and slowed the whole operation down. Thinking back, this was the single most important call I have made for our company and the most beneficial. Because if you are speeding along in the wrong direction, it only means you're getting farther a lot quicker. We were building useless features, we were building them poorly, and our team was wearing out. The number of bugs being found was taking up more and more time, trending up towards infinity. Hitting the brakes and refocusing on what needed done was exactly what we needed.

Lesson 6: Moving fast without direction is the quickest way to get the farthest from your goals.

We worked on bugs for months. It was tough. I had the buy in of my boss but it was still difficult for him to see no progress. I had to balance fixing our foundation with adding features our startup needed to survive to get funding. It paid off, the app started to become a lot more usable so more people starting using it, and our numbers went up.

We were making some real progress but for a team of our size it kept feeling like we were moving slowly. I attributed this to my lack of experience, surely there must be more hidden areas that I have yet to learn about. This next lesson was the hardest to learn and it still stings a bit. Our output was lower than we liked, and even with the slower pace, the quality was still rather low. My team seemed distant and had little passion for what we were doing. They didn't seem to care. If the site went down, they were slow to respond. During discussions they had few inputs and suggestions. I attributed this to the fact that they had been burnt out and I worked hard to get them back on board. I woke up at 6:30am every morning so I could video chat with our team over seas at 7. Some nights I stayed up until 12 so we could review things. I would know all the latest news in their home country and discuss it with them. I made sure to show them that I valued their work and give them praise for their accomplishments. I knew my team, I knew about their lives outside of work, about their families they cared for, and I believed I had their friendship.

Lesson 7: You can't build a team without trust.

I continued to try and connect with my team and get them engaged. The overseas team seemed to do a lot better but the U.S. team still seemed distant and detached. To make a long story short, we learned that they were doing other projects during work hours with each other. So, we transitioned to a new team and then let them go. It was the hardest thing I faced. Not just that I had poured so much effort into this team, into our working relationship, but that I had trusted them as friends. We went from a team of 7, down to 3.

The new team we contracted with handled the transition well and it allowed me to take those same learning and strategy and start fresh. We planned out our processes, used new tools, and they taught me even more I didn’t know through their own experiences. This fresh start allowed us to move in the right direction and even though we were moving slower and with less people, we never moved backwards through bugs, bloated features, and bad code. So even with the reduced paced it felt like we were making more progress than before. We weren't creating more bugs, we cut page load times in half, we added well thought out features, and we became friends. The team is now invested and engaged and it shows. The product is stable and moving in the right direction because they take part in every part of the product life cycle. This engagement and structure has give me even more free time, time to think about the products future and get back to designing.

Lesson 8: It’s never too late to start over and do it the right way

So now here I am more than a year into this position and suddenly it feels second nature. I am confident about the direction we're headed and the team at my side. I guess learning by fire is a good way to learn. I can't wait to learn more about leadership and to grow professionally and as a person. I am looking forward to more of the challenges I will face.

If you enjoyed this article, please feel free to follow me on Twitter for more* and recommend this article here on Medium.

*Don't worry, there I'm a lot more pithy.

Also, special thanks to Husam for his excellent help editing this rather long article.