How would one define the scope of UX

Question

So part of my job involves reviewing existing applications from a UX perspective and then take a consultative approach and suggest improvements. This task however runs in parallel with other teams who also review the application but from other perspectives like functionality, performance, security etc. All teams work pretty much in silos.

Recently I came across an application where the user would receive some data from multiple sources (cannot provide specific data as it's all proprietary). This data is then tweaked using the application and then a final report is generated. Basically once the user is satisfied with the tweaked data, a button needs to be clicked and a PDF report would be automatically generated.

While reviewing the application, I realized that the report did not display some of the data appropriately. Basically if part of the data was 'x' and the user changed it to 'y', the report would still reflect 'x'.

I documented this as a UX issue, however my boss said that while this would affect the user experience, it should be categorized as a functional issue rather than a UX issue as it only means that the application isn't functioning appropriately.

While I agree with his point, I still felt it could also be categorized as a UX issue because the user would be performing a set of tasks to accomplish a certain goal(in this case generating the report). However, when the report is not the way the user expected it to be, it would lead to frustration.

This thought got me thinking further, all issues, whether functionality, performance, security, compatibility would all directly or in some cases indirectly affect User Experience. Hence any and every issue in an application could have a UX angle to it.

So in such cases, how does one define the scope of UX as compared to other facets of the application like security, functionality etc.

I understand this could be a little broad and subjective, hence to make it a little more objective I've reworded and made it a little more specific below

• Are there any standard parameters / principles / rules of thumbs in distinguishing an issue a UX or non UX one

• Has there been any research / paper / article written around this area

• While answers for all contexts are welcome, this question focuses more only for scope when it comes to tasks like review and assessments.

Answer 1

As I never tire of saying, everything exists on a spectrum. There are no black and white scenarios in the real world. Everything affects the end user experience, but not all of it falls into the scope of responsibility of the UX role. From the top to the bottom of the organisation, different people have different responsibilities, different views, different reasons and different interests and interpretations relating to the product, its functionality and the user experience.

Consequently, in a UX role, it's impossible to design the user experience, simply because it's affected by everything, and more importantly, everyone at some level. That also includes the differences between each user and their environments. We can't design users and we can't design situations. The best we can do is design for an intended experience.

So given that the UX designer role already has some pretty big constraints right there at the user end, it's not unreasonable to also constrain our responsibility at the product end - in the organisation. While it's important that UX designers are good at their job, any decent manager will tell you that the best thing they can do is hire people who know more than themselves - the right people for the right job. So while security, performance, compatibility etc are all areas with which it's useful to have a 'UX finger on the pulse', those are areas best left to the experts, while supplying some user touch-point guidance where necessary.

The converse of that is that as a UX designer, there are areas where you are the considered expert. Others will want to have their own 'finger on the pulse', but these areas are best left to you, while they supply some touch-point guidance related to their own interests.

Sometimes depending on knowledge distribution and areas of expertise (or lack of) it's unclear who is the expert and it's a matter of collaborative discovery and development.

In other words, the key things are working together, communicating, and sharing. Sometimes as an expert, sometimes with an expert, and at every level between.

"All teams work pretty much in silos" you said. Right there is the problem.

Silos kill this. They kill the communication. They block that spectrum of in-between-ness. They enforce a binary decision of 'is that my area or not', when in almost every case it's just not that simple.

Embrace the uncertainty. Embrace the spectrum.

Answer 2

In general it depends on how you're operating within the organization/with the client. If you are within an org and work side-by-side with other teams, then your work is part of the larger system and can only be gauged in those terms. So both you and your boss would be right: the UX has a problem because of a development failure, but once that failure is fixed the UX problem is fixed too (in theory...this rarely fixes it in reality).

Then again, if you're working with clients and you have little to no control over other parts of the development process, then once you deliver specs and design documentation, you're done. It's up to the client to follow through with your work. Should they keep you on payroll with the intention that you'll oversee the work, then in theory it depends solely on the scope of your role.

I had this happen last year (like 8 months back) where I was brought in as a UX consultant for a company working on a Slack bot. I just went through the regular process of designing the registration and communication flows and once that was done, in theory I was done. But the client also wanted someone to handle the day-to-day and make sure that the development work was done per my spec; this meant that while I had completed my UX work, I also oversaw the development of that work.

In reality, that wasn't UX work at all. My overseeing was anything from Project Management and QA to basic babysitting. And I was paid for it, and didn't mind since it required often little oversight from me.

For contractors/freelancers this is something that must be listed very clearly in the contract. If it's within an organization and you're not comfortable with taking on additional tasks that aren't included with your job description, then you should bring it up to your boss and/or HR.

Answer 3

In my opinion user experience is intertwined with every engineering aspect that supports it. That because form, function and aesthetics are intertwined. User experience should not be isolated. It is an aspect of the engineering efforts to develop the applications.

In your specific case, you boss is absolutely right. This is a bug. A very bad one. Your description is a bit vague, however it seems to me a complete failure in the primary uses of the functionality (change then print). This is unacceptable to me. Bugs are part of life, but a primary function not working is sign of improper testing procedures.