1

I'm just curious if my opinion is outside the norm. I work at a large corporation with a 200+ person IT department -- which includes 2 UX Architects, 3-4 frontend web developers, and a couple graphic designers. The two ux architects are the only people doing real ux work -- research, strategy, design, development. The other positions are primarily just HTML/CSS coders and graphic designers (nothing wrong with that!).

I've been trying to convince leadership that we need a UX department because we have zero standards and zero collaboration across multiple enterprise applications, but I'm not having much luck.

The current structure consists of many scrum teams filled with software engineers + 1 ui/ux related person that does some form of design and frontend development.

Am I being too sensitive about this or should a multi thousand employee company with a 60 million dollar IT budget have a UX team that creates standards and then farms out UX designers and developers to specific projects?

Should engineering teams have a UX person always on the team or should a UX team assist the engineering team?

Thanks.

  • 1
    I think this question may be slightly too opinion based, and could be restructured as 'What is the benefit of having a centrally managed UX department vs satellite UX teams?' – Midas Mar 30 '16 at 22:25
  • 1
    ^ exhibit A: "The whole company should UX." – plainclothes Mar 30 '16 at 23:37
  • 2
    of course, I agree, but you see my point, right? – plainclothes Mar 30 '16 at 23:38
  • 1
    @plainclothes point conceded :D – Michael Lai Mar 30 '16 at 23:48
  • 1
    I assume that you are one of the two UX architects? If so, what is the other person's view about this. Two voices are usually louder than one, and the louder your voice the easier it is to be heard (or become annoying so people just agree with what you say). – Michael Lai Mar 30 '16 at 23:50
1

To the question: 'What is the benefit of having a centrally managed UX department vs satellite UX teams?' I would say that one structure isn't better than the other, it just depends on the way the rest of the organisation is structured, and how projects are managed.

Conventional wisdom says that centralization will work better if you want to establish and maintain standards/processes. Yet often we see standards and guidelines ignored because it is too cumbersome and therefore not accessible or visible in large organisations. My rule of thumb is that the more standards you have the less communication is required, and the less standards you have the more communication is required. So you have to decide what works better for your organisation and where the balance between standards and communication best fits. Having said that, you should plan for where you want to be rather than where you are at the moment.

The opposite approach of a distributed team has practical aspects if people work in physically separate locations or across different projects and therefore the flexibility of an organic structure suits the rapid pace at which things change within the organisation. Often organisations have to transitioned between having small teams working on experimental or start-up type of projects, and once the product or service is integrated into the main product line then those standards and guidelines will need to merge with the rest of the organisation.

I find that in organisations without standards, invariably the implementation work will grind to a halt due to the inconsistency in the look & feel, at which point the finger gets pointed at the UX people. And if you are going to work with external agencies and outsource the work, it becomes even worse because different agencies will do things differently. But the fact is that you will find this to be the case in large organisations so it is not something out of the norm. What you can actually do about it depends on how you want to go about making change, and how willing people are to accept change.

3

I would rephrase your question slightly: Should UX be embedded in an application team, or should it be a centralized resource? Embedding UX in the application team allows the UX professional to understand the needs of the team, and often have better access to users. Having it be a centralized resource allows the UX professionals to have better access to their UX peers, and helps engender a more consistent user experience because the UX team works together.

You've stated what is, potentially, a real business problem: a lack of consistency between your applications. Conduct research to determine whether this really is a business problem. Are you losing sales because your users can't extend their knowledge of how to use one of your applications to another one of your applications? Do users complain about the lack of consistency? Are there support issues that can be traced to the lack of consistency?

Gather data to support your assertion, and brainstorm solutions to solve that problem. Potential solutions include standards and collaboration, which might or might not mean that you have a central UX organization. Standards are going to be difficult to implement in an organization that has historically let each team do what it likes. Collaboration is often an easier sell, and might eventually get you to the standards that you think are necessary.

Personally, I've done it both ways. I was part of a centralized UX team at a large enterprise software company, although there were also individual designers sprinkled on application teams. That central UX team developed standards which were adopted by the company's flagship product, and slowly but surely adopted by other products as well. In this case, collaboration was still a challenge, especially for those individual designers embedded within teams. Creating opportunities for collaboration was a huge win in that environment. I've also been the lone UX professional embedded with the application team. I was able to be very successful in working with the team to get UX improvements into the product because I knew the application very well and was able to take part in prioritization exercises. I also had fantastic access to my users, which made user research easy to conduct. Since I was with the dev team, they often attended my user research sessions, so they were more invested in UX overall.

There is no single answer here. Determine the business problems that your UX team(s) need to address, and determine the right way to address them. Consider it user research of your own organization.

1

"Should engineering teams have a UX person always on the team or should a UX team assist the engineering team?"

I think it should work both ways. UX team can assist the engineering team by One of the benefit of having a UX person always on the team is the team has a go to person when they encountered a difficult scenario or unexpected scenario. UX person can help them propose a solution or an alternative. Although the UX person is not always needed by the engineering team, it would be best to for the UX person to work on standards or document standards so that the team will have a reference that they can go back to.

Standards are guides to help both UX person and Engineering department. If the organization have standards to follow then all the applications will be consistent. There will be lesser stress / tension in creating software applications.

1

If there is a software department, there should be an UX team. I'd bet those UX architects (Information architects?) you've mentioned are overbooked and cannot deal with all the workload. Graphic designers being a separate entity and not a visual design competency of UX department seems problematic, too.

Not the answer you're looking for? Browse other questions tagged or ask your own question.