It Takes a Product Design Team to Build a Product Users Will Love
I’m a software engineer who joined OutSystems in 2007. Since then I’ve learned a great deal and become a team leader. Along the way, I discovered usability and design practices. I’ve always been one of those people who really cares about our users. Yes, I’m the guy who experiments with mockups and prototypes and who does usability tests before shipping the product. So, OutSystems asked me to build a product design team. During this process, one thing became clear: a steady, strong, and high-performance product design team adds value to multiple projects.
Fortunately, I was able to capture the process along the way so that others can do it, too. So, let me lay it all out for you, starting on the ground floor.
The Main Ground (Floor) Rule
If you want to build a great product, having a few people who care about user experience is a good start, but it’s not enough. You have to do things differently. So, the main ground rule for your product design team is that it has to be multidisciplinary. By that, I mean that it has to have UI designers, UX designers, and software engineers with a development background.
Why is this important? Because any app you build has to take into consideration the needs of the users and its developers. Otherwise, it might satisfy the aesthetics from the UX/UI design point of view, but it still might not work for anyone else.
The Early Stages: Define Your Purpose and Vision
If you’ve had design-only teams in the past, it’s possible that they’ve 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, mugs, and other amazing swag. This needs to change.
To shape the future of your product (and not be brought in as an afterthought), calling your team the “product design” team and muscling in at the beginning is the best way to start. This is because, for any product or app, this team should influence how engineers and developers design the product in its various aspects. In other words, the functionality, usability, usefulness, and, yes, the visual aspects of the product should all fall under the product design team’s purview.
After this hard work is done, you should create your vision. Here’s an example of the OutSystems Product Design Team’s vision.
Next, define a set of goals that you apply to every project you work on. These goals will guide you to your vision. To inspire you, these are the goals we used for ours (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.
Project goals keep you on track, remind your team of what’s important, and enable everyone to stay focused on what you’re hoping to achieve. However, having goals doesn’t mean your team will automatically be a success. There are other things you’ll need to do.
Running a Premortem
More than a decade ago, the Harvard Business Review published an article about a useful technique called a premortem (more here) that helps forecast project risks. In a premortem, you imagine a future failure of the project and ask each person involved what might have contributed to that failure. Then, adapt your plans to avoid these hypothetical risks and steer clear of failure. So simple and powerful, right? It is, believe me!
For your team’s premortem, the hypothetical setting could be that after one year, the team failed spectacularly. Ask everyone on the team what they think caused the failure. From these hypotheses, you can identify common concerns and define action items for preventing them. Some of these action items can be executed during the team bootstrapping, and others can be ongoing. A number of ours have continued since their inception to make sure we don’t fall off the cliff.
Assessing Skills
The multidisciplinary nature of your team can be a risk itself. Meshing diverse skills is often challenging, so mapping them out is a must. A definition of the term “product design,” can help. This one is useful:
Product design identifies, investigates, and validates the problem and ultimately crafts, designs, tests, and ships the solution.
When you adapt this definition to your specific needs, you can start shaping what it means to be a product designer at your company. Here’s the diagram we created in 2016; feel free to use this as a guide for your own:
Next, do a skill self-assessment for your team. Include what you would like to develop or where you can coach others. That way, you’ll be able to identify where members of your team need training and if you need people on your team. In our case, we also used our assessment to determine that we should always work in pairs because it enables engineers and designers to learn from each other while complementing each other’s skills.
It’s a good practice to repeat your self-assessment because times and technology change. This is our latest diagram:
Working With the Product Teams
With the team in place, your vision and goals set, and your skills determined and clear, how can you actually influence the future of the product? It’s likely that your company has several product teams, one for each area of the product: front-end, back-end, application lifecycle, and so on. Or if it doesn’t, there will certainly be other teams that are part of the process. Therefore, I advise making sure you following these two simple rules:
- Work with the teams, not for the teams
- Always aim to add maximum value and the least overhead.
You will also need a well-defined process so other teams know when they can count on you. Our team’s process has four stages that you might find easy to incorporate into yours: discover, prototype, deliver, and tweak. We go through all these stages with our product teams, so that everyone is involved in the design process from day one until people 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 adapting the process to new techniques and new requirements. In fact, we tweaked it during our experiments. Let’s take a closer look.
The Discover Stage
In this stage, you work to understand the problem your product will solve. Interview people, gather feedback, do usability tests with the current solution, analyze the competition, and run an ideation process to come up with as many solutions as possible. During our ideation process, we experiment, and, as a result, we now run a variation of the Google Design Sprint that we call “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, you prototype solutions for the problem, test them with target users, and iterate them. The prototypes can be anything from paper to software prototypes. At the end of this stage, you will have tested several, so you know what works and what doesn’t. Our team works closely with the product teams that will be implementing the solution, and at the end, they decide which solutions to implement.
The Deliver Stage
During this stage, the product teams build the software and product design provides visual assets, reviews the implemented software from end to end, and runs usability tests. Testing the working software will enable you to discover any usability issues, adapt solutions, and, if necessary, build alternate prototypes. At the end of the delivery stage, the the product ships, and you can celebrate this with the team!
The Tweak Stage
At this stage, you take feedback from actual consumers or end-users and look at metrics to tweak the delivered solution. The goal is to determine what isn’t working and what might work better and then make quick fixes and plan future improvements. For example, as shown here, we identified how many different ways the users accessed the functionality and which was the most popular. This information helped us simplify the design.
Where Your Product Team Can Take You
After building a high-performing product design team, you’ll notice something amazing: user experience will become part of your culture. You’ll find it easier to collaborate and build bigger and better things.
Oh, you’ll probably still have challenges, because in our business, nothing stands still. But if you’ve built your team right, it will be rewarding and fun to overcome them and find new ones.
In the case of my team, we need to scale to influence more projects. We need to keep working on our vision for the future. And, we need to improve our synchronization with product managers and product owners. There's lot’s to do, so let’s roll up our sleeves and get busy!
