From Product User to Product Designer
By: Daniel Reis
Tags: Product Design, User Experience, UX, Outsystems, Company Culture

My mother says I’m restless, my wife says I don’t know how to relax and enjoy the moment, and I say that they’re both right. My academic background is in architecture. I later moved to development, where I was exposed to all kinds of different perspectives, and recently figured out that product design is where I really wanted to be.

But let me explain exactly how this happened and why it made me a better product designer.

Me, Myself, and I

I joined OutSystems as a developer in 2014, and I was part of the team that built the first version of Silk UI, a low-code UI framework with templates, samples, and patterns that accelerates UI creation in the OutSystems platform. It was the precedent of OutSystems UI, which was made by really smart people. Even though my architecture days were long gone, the work methodology and analytic view were valuable to me.

As a developer, this was the first time that I’d caught a glimpse of something huge. I remember being radiant because I wasn’t building yet another website, something I did all the time. Building a tool that would improve the work of developers all over the world filled me with adrenaline, but also with a sense of responsibility. I was finally moving to the grown-ups table!

But not everything was a bed of roses.

The Wake-Up Call

After building the Silk UI framework in our Batcave over a few months, I went to our beta customers to provide support with the challenges that they might encounter. I was extremely confident in the work that we did, having put serious thought into finding the best approaches for each pattern before developing them with care and testing them in multiple scenarios.

Therefore, I expected I would only be there to receive all the praise for the amazing things that we’d built. Nothing could go wrong, right? Well…

For the first time, I saw other people using what we’d built and I instantly realized that developing perfect code isn’t enough. I was proud of the work that I’d done as a developer, but I never tried to ensure that users in general, regardless of their background, would be able to experience Silk UI as we’d intended.

I specifically remember a few developers trying to use the Calendar pattern inside the OutSystems platform. They wanted to use that pattern in their code, but at the time, the pattern had over 20 parameters to get through! Oh boy, was it hard for them to deal with all that information and all those configurations. It would be easy to blame the users for being unable to understand it correctly, but I didn’t (not for long, at least). It was my fault; I built that pattern.

We planned to cover several advanced use cases with that calendar, but to achieve that, we’d added unnecessary layers of complexity for every other user, including those who just needed a basic… calendar. It wasn’t intuitive at all, and there was no reason for those developers to be challenged by such a simple task.

As an OutSystems user, I was once just like those guys, and I realized that sometimes I also struggled with a lack of intuitiveness. For instance, I remember how painful it was for me to use our Charts pattern back in the day. But when I was wearing my developer cap, I wasn’t thinking like a user, and I wasn’t addressing user problems. It was like we were speaking different languages.

To understand what was missing, I had to put myself in the user’s shoes.

Different Perspectives

For the next three years, I worked in our Customer Success department. Throughout the countless projects I’ve worked on, I’d noticed that developers were using our product in ways that we hadn’t even imagined. They were finding alternative means to achieve the same goals for which we’d already outlined solutions.

Given that, we had two responsibilities. One was to understand why users were taking shortcuts to accomplish their goals in the platform. The other was to design solutions that would better meet their expectations while preventing misuse of the product.

As I identified all these pains that users had, my empathy for them grew. I was enjoying getting lost in their problems and understanding their point-of-view, but there was still one more stair to climb before an unexpected turn of events.

Further down the road, I became the team lead of the front-end and mobile experts in our Customer Success department. Most of the code we built was tailor-made for our customers and it would be used and maintained by OutSystems developers. One of our golden rules was to build functional code that any OutSystems developer could understand.

The focus was now officially on the user. It was then that I realized that I was obsessed with finding solutions for each problem. It was crystal clear, I wanted to think more about the product, and less about the code itself.

When the team heard that I was leaving, they were quick to find capable replacements.

I decided to move away from development and embrace a whole different adventure in a team with a different mindset and people that could help me improve myself.

The product design team was the right team to be on.

The product design team on a team building event.

To Be in Love With the Problem

In product design, I found a team that doesn’t want to have just the Cristiano Ronaldos or Messis of this world. Here we need different players with different skills, people that can see things from a different perspective and change the game as a team when needed. People that can identify the blind spots of teammates and cover their backs.

This was the perfect mindset for me. I’m that guy who spends a lot of time researching places to travel, documenting my research in several spreadsheets and text files, covering every possible plan, and predicting best and worst-case scenarios. Only then will I guarantee the best possible trip, as I’ll know exactly what to expect and how to get around any tricky situation that may come up. I just love doing this, so why shouldn’t I do the same for everyone that uses our platform?

And how do we do it? I’m glad you asked. We collect the data we need to understand the truth before jumping into solutions, and we hold ourselves accountable for the outcome. We always embrace the problem and dive deep into it by uncovering data, interviewing real users and proxies, looking into the product’s telemetry, collecting reports and business metrics and understanding the whole user journey.

Only when we understand the real problem will we be able to start working on a solution.

Product Design’s Telemetry Dashboard.

Our job is to give the team and stakeholders confidence, guaranteeing that we’re on the right path. We achieve that by clearly communicating the story we want to tell. If we’re finding it hard to be understood, it’s because our story still has flaws. It means we’re making decisions based on assumptions, leaving room for blindspots that won’t let us go in the right direction. When this happens, we repeat the process until we can support our ideas with proper data.

We start by asking high-level questions, such as “What use cases are the most important?” gathering insights from the answers. Then, we’ll be able to dig further and start another round of gathering feedback by asking our users about their ideal user journey, for instance. We’ll repeat this process as many times as needed until we understand what the problem is, why it’s a problem, how can we solve it, and how we can make it easy for users to find the solution.

We do this because it’s always a challenge to understand the point when, right from the start, we’re biased or too confident about the solution. So it’s important to revisit our principles — the ones we initially choose as the foundations of our problem — trying to validate our solution through them. Only then will we be able to start moving in the right direction.

For instance, if my problem is “I want to go from point A to point B in less than one hour,” I need to understand the impact of solving my problems by using a car, a motorcycle, or a horse or simply by walking, along with the impact and costs of each option. Only then will I be able to choose the right method.

If we start by assuming that the solution to my problem is the car because it’s faster, I may end up realizing that I’ve spent a lot of money on a car when I could’ve just walked for a mile to achieve the same result. If I designed my entire solution based on the assumption that a car would be better, shouldn’t I reconsider it if, for instance, teleportation becomes a reality in the future?

It’s always a matter of deconstructing what we already know, to start questioning why we think that way. The problem should always come before the solution.

This Is My Story… so Far!

These are the things I truly believe can make a difference in product design. We should always know the amount of investment needed to solve a problem, be aware of the risks, and frame the consequences to understand if a solution is the best one.

We need to be bold and innovate and, at the same time, advance with care and collect data from the field. At the end of the day, all you have to do is act as your own devil’s advocate, weighing both sides to move forward with the best possible solution for your users.

If you’re working on a product that’s already on the market, you need to understand that you’re accountable for the changes you make. The product already belongs to the users and they expect changes to improve their experience in some way, and not the opposite. Again, it’s always a question of understanding what their problems are and finding the correct solutions. And whenever it’s possible, there’s nothing better than going directly to the source to observe your users using the product, just like I did when I assisted other developers that were using my Calendar pattern in Silk UI back then.

I believe that the knowledge I bring from having field experience has helped the team. Every single one of us has a different background, different concerns, a different story, and a different vision. These different perspectives help us avoid assumptions or instant solutions for new problems.

If you also like being in love with the problem and are passionate about finding the best possible answers… maybe product design is the right place for you!