I spoke previously about the relationship between Engineering and Product Management.

The next area I want to comment on is the UX area which, along with product engineering and product management, forms the core product development team.

What is UX?

Here’s a good definition of UX from Nielsen Norman Group:

User experience encompasses all aspects of end-user interaction with the company, its services, and its products.

This is a fairly simple definition, but it does cover all aspects of UX. Software developers tend to think that UX is the interface of the digital product, both from the point of view of planning user interaction with the product and from a visual point of view. Yes, UX is that, but not only that. UX is also concerned about what this product causes for those who use it.

According to ISO 9241-210, entitled Ergonomics of Human-System Interaction, which provides guidance on human-system interaction throughout the life cycle of interactive systems:

User experience is “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service.” According to the ISO definition, user experience includes all user emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and achievements that occur before, during and after use. ISO also lists three factors that influence the user experience: the system, the user, and the context of use.

UX in the Product Development Process

In the product development process, UX is responsible for thoroughly understanding the user and the problem to be solved for that user. The following figure illustrates well the role of UX as well as product engineering and product management in the development process.

In product discovery, UX has a central role. The first step is to understand the user, the person who will use the digital product. For this, UX uses a tool called persona, which represents a group of users with similar behavior patterns, attitudes and motivations in terms of purchasing decision, use of technologies or products, lifestyle, etc.

Personas are used to:

• Know and understand customers and users of products and services;
• Bring the user to the project focus;
• Make design decisions more humane and less abstract.

The following figure shows how to build a persona:

The first step is to define a name and some characteristics of this persona. This helps in conversations about the product. In the name, it is cool to give a hint of the main characteristic of the persona. For instance, Maria, the cool girl or Michelle, the busy woman.

If you are making a product for Michelle, the busy woman and want to insert a new feature, the question is: “Can Michelle, the busy woman be able to use this feature? Will she find it useful enough to find time to learn how to use it.?” In addition to the name and basic characteristics, it is also important to describe the behaviors and problems. The following examples will clarify the concept of persona.

Maria, the cool girl is one of the personas we used at Locaweb. Given the different products we had in our portfolio, we ended up building eight personas. However, for each product in our portfolio, we have about 3 or at most 4 personas, one of which is the primary product persona, that is, for whom all your software product decisions are made.

Then, based on a lot of research to fully understand the problems and needs of these personas, UX builds the prototype that will begin to materialize the product idea. This prototype should be used in conversations with customers and users to validate if the idea makes sense, as well as conversations with the product engineering team so that they can already understand what lies ahead and whether technology is available to do so.

It is very different to hear a product or feature description. For example: imagine someone telling you that “you will see a screen with login and password, and an enter button. You will also see a link if you have forgotten your password”. It’s not easy to picture this without a real image. The first version can be a paper or whiteboard drawing:

The prototype is also very important as a communication tool with product engineering. Showing the prototype makes it easier for engineers to evaluate the difficulty of implementing each feature.

When I made ContaCal, as my drawing skills are not the best, I chose to use PowerPoint as my tool for drawing the prototype:

Once the basic features are agreed upon, this prototype can be made on a computer. The first version of the prototype made on the computer is usually only in black and white, with only the contours of the elements, and no images. This version is often called wireframe:

The next step is the UX team preparing a usable prototype (or wireframe), that is, one that already has the interacting behavior for you (product manager and UX analyst) to show customers and users so that they can test and interact. Next, the UX visual designer begins to put color and shape on these screens to make them the version the users will actually see.

With a prototype in hand, usability testing can be done to identify usability issues or validate interface solutions. To do this test, users are invited to perform certain tasks on the prototype. During the test, you can observe user behavior when performing a set of proposed tasks, and identify the difficulties and motivations behind some of their decisions when interacting with the product. The user is encouraged to verbalize his actions, opinions and feelings so that we know the mental model created by him.

This prototype will guide the engineering team in developing the product. It is the specification of the product, but remember that it is not written in stone. For this reason, the UX team doesn’t deliver the prototype to you and the engineering team, and then they go do something else. The UX person who designed the prototype should continue with the product manager and engineering team as it is being built to adjust the prototype (if necessary), discover improvements, and bring the engineering team closer to the user’s needs.

What else do UX people do?

Another point where UX people actively participate is in defining and tracking metrics. As I said in the What is a roadmap? article, every item in a roadmap must have its motivation and its metric. The UX designer should know very well what this motivation is when she designs the prototype and should work closely with the product manager and engineering team to define which metrics to follow to measure if the motivation has been hit.

The UX person also talks a lot with the user. She will be your primary companion in these conversations and interactions with the user, and will always be focused on what is best for the user. Your role will always be to bring the rest of the context, that is, besides being good for the user, it needs to be good for the company that owns the digital product you are developing.

It must also create interaction patterns. Every time a new feature is developed, you shouldn’t be drawing it from scratch. It is important to have an interaction and design pattern library. At Locaweb, we created Locaweb Style, with our interaction patterns, and published it as open source.

What is the relationship between UX and product management?

As I mentioned in the previous chapter, the fact that the product manager is responsible for defining the product to be made can give the impression that UX reports to product management. This is an incorrect view, and if the areas see it with this reporting structure, the chances of the product failing increase because people who feel subordinate have less commitment to the outcome. UX and product management, as well as software engineering, should be viewed as a team, with no reporting relationship and functioning as collaborating partners to produce the best product possible.

UX will always feather their own nest focusing on the user’s side, and will always want to do what is best for them from both function (interaction) and form (visual) points of view. And that’s good! If the UX team is a good team, they will always be feathering their own nest to make the most perfect product from the user’s point of view, just as the engineering team will be feathering their own nest to the technical side, always proposing to rewrite the product and each feature since they just found a better technical solution. It will be up to the product manager to defend the interests of the company that owns the software and find and proposes a balance between these needs.

Oh, and there’s one more thing!

Like product engineers, some UX designers turn out to be great product managers. It’s important to be able to figure out when a designer is looking for “something else to do” and give him that career choice. At Locaweb we have great product managers who were UX designers. In some cases they ended up becoming product managers of the product of which they were responsible for UX. On the other hand, there are also some UX designers who try product management and don’t like it.

This situation is less common because, unlike the product engineer, the UX designer is normally used to talking a lot with the user and other product-related areas, so product management work is not so foreign to him. Even so, you have to leave the door open for him to be able to become a UX designer again, without prejudice to his career.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.