Who should make the final design and UX decisions on a team without a designer

Question

Our team doesn't have a dedicated UX/design employee. Is is better for product or the engineers to have the final say for UX/design decisions? Or should it be a majority vote?

Answer 1

It's the product owners duty to define acceptance criteria. This can include usability features.

For example: As a color blind user, I want to use this feature without any impediments

It's the engineers duty to figure out how to do that.

For example: Subtask: As a user, I want my color blindness settings from the main application to take effect when using this feature

OR

Maybe the engineers decide to use a thumb-up / thumb-down instead of a red/green traffic light here.

Whatever you chose. the Product owner says what he wants, the engineers decide how this is done.

UX is how.

Answer 2

My advice:

• Set aside time for your team to learn some basic UX/usability, whether it's looking over blogs or videos together or actual training. Even if you get a dedicated person later, helping your team become more T-shaped will pay dividends.
• Work together to create a proxy for a UX designer, i.e. a visual style guide that can be followed by almost anyone when implementing something, and referenced in discussions.
• If your product goes beyond simple functionality, you should consider incorporating guidelines for how a user should feel when using it. This will drive important discussions around specific decisions.
• Do what you can to get that true UX/usability member, even if it's just a part-time contractor putting their eyes on the most critical pieces like the style guide, large changes, new features that set precedence, etc.

Edit: almost forgot the most important point - validation! Do usability tests, get user feedback, and involve as much of the team as possible - there is a much higher chance they will own the iteration and solutions needed when problems arise, and they get a chance to be closer to the user perspective. Even with a dedicated UX member taking the first stab at designs, true user validation is invaluable.

Answer 3

I would rephrase your question like this: "we are few people in a ship and none of us is qualified to be a captain. How should we navigate the ship - let the kitchen staff do it or have us all participate by majority vote?"

Of course, the right answer lies outside the two options you're suggesting. You must either hire an external expert or train (one of) yourselves in that job.

Answer 4

"Final Say" is a Business Decision; Consult the Framework or Charter

Is is better for product or the engineers to have the final say for UX/design decisions? Or should it be a majority vote?

The answer is: "Neither. Both. It depends."

Your underlying assumption seems to be that authority for making decisions rests on expertise in UX or product design, but it doesn't! Decision-making authority is delegated by the business, and the way this authority is delegated is usually spelled out in the project charter, corporate governance documents, or inherent in the project methodology.

For example, in a Scrum project the Product Owner (PO) would define an objective such as a login screen as a Product Backlog Item (PBI), and the Scrum Team would then collaboratively decide on how to implement it. In Scrum, this would be true whether or not there was a dedicated UX resource on the team. Other frameworks will delegate responsibility differently.

Our team doesn't have a dedicated UX/design employee.

You may or may not need one. There's nothing wrong with having cross-functional teams with shared responsibilities, and formal UX may not even be part of your project's critical path. However, if specific expertise needed to successfully delivery the project is lacking, then this is a process issue that should be made visible to senior management so that they can address it or accept the associated project risk.

Answer 5

In agile we try to achieve as much as possible by consensus.

Try and build a working relationship between the product people and engineers such that consensus is reached frequently and there is no need for a vote or for one party to be given final authority.

As an example, you could reach agreement that the product people get to decide the overall design, but that the engineers can decide on the details. Or you might agree that a style guide is followed but that product people can make decisions as long as they do not conflict with the style guide.

The important thing is to have an approach that allows everyone to feel comfortable with the design.

Answer 6

There are some open variables in here:

• How big is the product value based on its design/UX attributions?
• How "sexy" is the product?

In general (specially if the answer is "low" for the previous questions) I would say the PO/PM should make these definitions. Some of these definitions will even be easy to make as some business requirements rely on UX/Design definitions.

However, a wise PO would ask for inputs of his teammates who have a deeper (or even some) knowledge/experience with UX. Also, the company and/or the team should definitely find some qualification on that skill as this need probably won't disappear :)