Build a Product Design Team, Build a Product Your Users Love
In July of 2016, I was invited onboard the most ambitious project in OutSystems Engineering: to join a group of people passionate about UX and form what is known today as the Product Design team. This team influenced how engineering builds the product to the point that user experience is becoming entrenched in our culture. Let me tell you the story of how we got here.
My Story
I am a software engineer who joined OutSystems Engineering back in 2007. Since then I’ve been doing and learning a lot of technical stuff. I became a team leader, and along the way, I discovered usability and design practices. I’ve always been one of those people who really cares about our users, the guy who experimented working with mockups and prototypes and who did usability tests before shipping the product.
that they sent us a happy New Year letter.
However, if you want to build a great product, it isn’t enough to have a few people that care about user experience. The company realized that and tried (and failed) to create and maintain a centralized UX or design team. So, why was I being invited to build this team?? Well, as you will see, the reason was that, this time, we were going to do things differently. After a successful trial run in an existing team, management accepted our proposal to build a brand new design team.
A ground rule for this team was that it had to be multidisciplinary: contrary to previous iterations, it had to be composed of both UI/UX designers and engineers with a strong software development background. Why was this important?
OutSystems offers a low-code platform for building mobile and web applications. Our ultimate purpose is to improve the lives of developers by making development faster and easier. To understand those developers, discover their needs, and design and validate the best solutions, we need both engineers and UI/UX designers. I would be the engineer and also the team leader for this new team, and that was a major challenge!
The Early Stages: Defining our Purpose and our Vision
The first important decision we made was to name the team “Product Design.” We wanted to break from the past design-only teams. Unfortunately, these had been limited to the later stages of the projects, working only on the visual design (images and icons) and other design stuff that the engineers can’t do, like t-shirts and mugs, and other amazing swag.
We wanted to shape the future of our product and not be an afterthought; we would be involved from the ground up.
The Product Design team would influence how Engineering designs the product in its various aspects. We would influence the functionality, usability and usefulness of the product, and yes, also the visual aspects of the product.
With this we determined our inspiring vision:
Next, we defined a set of goals that we apply to every project we work on. These goals guide us towards our vision: deliver a product users will fall in love with at first sight and keep on loving forever:
- Make the product easy to use.
- Make the product beautiful and desirable.
- Help our users understand the product value.
In retrospect, our goals aren’t that different from those of the previous design teams, and we were aware that there is always the risk of failing like those teams did.
Running a Premortem
In the past, we have successfully applied a useful technique, called a premortem (more here), that helps us forecast risk in our projects. In a premortem, we imagine a hypothetical future failure of the project. We ask each person involved with the project to point out what risks may have contributed to that failure. Then, we adapt our plans, to avoid these hypothetical risks, and steer clear of failure. So simple and powerful, right? It is; believe me!
So, we decided to run a premortem for the team. The hypothetical setting was that after one year, the team had failed spectacularly. We asked everyone on the team to identify the possible reasons for the failure. From these hypotheses, we identified common concerns, and we defined action items to avoid them. Some of these action items were executed during the team bootstrapping, and others are still being executed to this day, just to make sure that we don’t fall off the cliff. :)
Assessing Our Skills
One of the risks we had identified was the multidisciplinary nature of our team. Complementing our diverse skills could be challenging, and at that time, we might not have the skills necessary to do our work. We accepted the challenges as a great opportunity for us to grow! And we’ve all come so far.
We looked into the definition of product. We found this:
Product Design identifies, investigates, and validates the problem, and ultimately crafts, designs, tests and ships the solution.
We adapted this definition to our specific needs and we started shaping what it means to be a Product Designer in OutSystems Engineering. We also created a diagram of the main skills that we would need as Product Designers.
Next, each of us did a skills self-assessment, we also discussed the skills we would like to develop, or where we could coach others. This gave us helpful insights on where the team needed training or more team members.
It also helped us define another ground rule for the team: we should always work in pairs, joining our engineering and design skills to complement each other’s great work and learn from each other.
We still do this exercise from time to time, and since the first iteration, we have continued to evaluate our skills. As a result, we’ve adapted the diagram to embrace our changes. Here’s our 2018 diagram:
Working with the Product Teams
With the team in place, our vision and goals set, and our skills determined and clear, how can we actually influence the future of the product? OutSystems engineering has several product teams, one for each area of the product: front-end, back-end, application lifecycle, and so on.
Another risk we had identified was that the product teams could decide to stop working with us if our processes interfered with their agility. So, we set a few more ground rules for our team:
- We work with the teams, not for the teams
- We always aim to add the maximum value and the least overhead to the teams.
We needed a well-defined process so that teams know when they can count on us. We researched several design systems, read books, and articles and gathered inspiration from other companies. There are a lot of design processes out there, but we needed to tailor a process to our own specific needs.
We defined a process with four stages: discover, prototype, deliver and tweak.
The Discover Stage
In this stage, the goal is to understand everything about the problem. We interview, gather feedback from multiple sources, do usability tests with the current solution, analyze the competition, and run an ideation process to come up with as many solutions as possible. We carried out some really cool experiments during the ideation process, and today we run a variation of the Google Design Sprint we call the “Design Session.” This is one of the most important stages of the process mainly because it aligns everyone with the problem we are trying to solve.
The Prototype Stage
In this stage, we prototype solutions for the problem, test them with target users and then iterate them. The prototypes can span several levels of fidelity, from paper to software. At the end of this stage, we will have tested several prototypes, so we know what works and what doesn’t work. We work closely with the product teams that will be implementing the solution, and at the end, they decide what solutions to implement.
The Deliver Stage
During this stage, the product teams builds the software and product design provides visual assets, reviews the implemented software from end to end, and runs usability tests. Testing with the working software gives us extra insights on usability issues, and we are open to adapt solutions at this stage, and if necessary, we can prototype alternatives. At the end of the delivery stage, the product is shipped and we celebrate this with the team!
The Tweak Stage
This stage starts once feedback from our users rolls in. At this stage, we look at metrics to tweak the delivered solution. The goal is to identify what is working and what is not, to perform quick fixes, or to plan future improvements. In the next image, you can see our analysis of the Styles Editor metrics. From the analysis, we identified how many different ways users accessed the functionalities, and which way was the most popular.
This information helps us simplify the design.
Lather, Rinse, Repeat
We go through all these stages with our product teams, so that everyone is involved in the design process, from day one until customers are happily using what we all built together. The process is adaptable and iterative; we can run it multiple times during a project. We are always open to adapt the process to new techniques, new requirements, and we did tweak it during our experiments.
Where We Are Today; Where We Are Headed?
Today we have a steady, strong, and high-performance product design team, and we have proved our value in multiple projects, some already delivered. We have worked with most of the product teams, and today all of OutSystems engineering understands the value of our practice. User experience is becoming a part of our culture.
We still have a lot of challenges ahead: we need to scale the team to influence more projects, we need to keep working on our vision for the future, we need to improve our synchronization with product managers and product owners, and so on. There’s lot’s to do, so let’s roll up our sleeves and get busy!
Back to My Story
This is by far the most challenging and rewarding project I have been involved in during my time at OutSystems. The challenges are constant; the team is amazing! Thank you, OutSystems, for such an extraordinary opportunity.
