Great UX Practitioners Do Not Design By Committee

I'm still recovering from seeing this some minutes ago in a conversation I'm in here. I had suggested that UX shouldn't be fed solutions, especially by product managers or design sprints. UX should be given all data, ideas, vision, customer feedback, etc. and be allowed to research, design, test, and do other tasks to find the best solution. It could be the solution a design sprint arrived at. It might not.

The response from the original post's author included, 

"Why only UX can come up with the solution? That part I don't understand. Why can't the whole team work on the solution together? Product managers, developers, hell even customer support? Do UX people follow all advances made in all fields that they can come up with the best solutions alone? They know the limits of AR VR IOT Database technology, capabilities of programming languages and so on? No. You need a whole team to come up with the best solution. UX designers can make the solution work for the customer."

Of course UX should be collaborating with other teammates. And research is UX's opportunity to learn everything we need to know that is relevant to this feature or product. But we don't design by committee. We don't go to all of these people - the VR experts, the database tech experts, the DevOps pros - and ask them what they think our customers might like and what product solution we should go with. We learn about best practices, limits, and possible innovations in these areas, in general or as they relate to our users and this project.

UX's job is absolutely not to take a solution that a mountain of people came up with together and "make it work for the customer." That's not User-Centered Design. Trying to push a design "everybody" came up with into "working for the customer" runs opposite to what a great UX practitioner should be doing. If you're doing that, you are probably asking what I call "interface scientists" to act as "short order cooks" and just wireframe the solution everybody else "came up with."

UX is Captain of the Product Design Ship

If this guy posting to LinkedIn got his way, evidently product solutions would be decided by asking everybody what they would build for the customer. Or maybe from design sprints. And then UX can work from there. But that's not how any company or team will create the best product for the customer.

Remember that the customer only cares about themselves and what they need. You should too, and that means not guessing or assuming what they want or need. Plenty of high-profile and recent UX fails remind us that skimping on UX rarely pays off in the short or long term.

Whether your call your UX practitioners UX Architects, Experience Designers, or Product Designers, they are your expert, specialized User Experience pros. They are focused on layouts, functionality, usability, and making everything easy and intuitive for target customers. I'm not talking about the visual designers who are focusing on color, typography, branding, and aesthetics. They're important, but first, we must get the blueprints and prototypes of this product or feature right. They must solve real customer problems.

When Your Car Mechanic Needs Help...

Let's say your car has a bunch of problems. Your mechanic has decided that they can't handle it themselves. They work with other people to get more information and angles on what might be the issue(s). They speak to 10 people, specialists in different areas, for ideas and possible approaches. They then synthesize this and try a fix. They can test the fix and see if the car is fixed or if they need to try another approach.

Your mechanic doesn't invite everybody they spoke to to get under the car with them and all fix it together. Your mechanic will fix the car based on good information and other ideas worth considering. UX is similar to this. We want to collaborate with all of those people but then it's our job to cycle through our formalized User-Centered Design process and research-build-test-iterate to find the best solution.

My new book, "DevOps ICU: Improve Processes and Results by Correctly Integrating UX (A Guide for Product, Project, and Engineering Leaders and Workers)", covers this and a lot more. It was written for all of the people who, like the quoted guy admitted, don't fully understand what UX does... why they do certain things, why they shouldn't do other things. If you need some help learning where UX fits into organizations, product, processes, software dev, etc, please check out the book as it might be the puzzle piece you're missing.