3

I work as a UX designer at a company with a team of BA's.

The BA's as expected gather requirements as expected, and I(the ux designer) prototype and design the interface.

However, I am required to run my prototypes by the BAs before sending to development which is where I am having issues.

I am constantly arguing about workflow and design features. The BA's are in my opinion overstepping there roles. They are dictating everything from information architecture to labels on forms and columns. Everything they touch becomes overwhelmingly complicated. They give the users everything they think they need, which usually ends up as a mess.

What are you experiences with BA's? If requirements are being met, who should get the final say in design of a product before user testing? I'm getting frustrated, I can't do my job if I can't make any decisions.

The other problem is there are 6 BA and UX designer, so not only does that make for a lot of arguing, but different analysts have different ideas resulting in very different design, making a very shitty and inconsistent product.

4

The governance over UX decisions is largely related to the structure of the team and organization. In the case where BAs and UX designers appear to work at the same level, you might expect a product owner or product manager to make the final decision.

I always believe that you need to foster a good working relationship with all people involved in the process for it to work, as UX is not something that has to be solved at the design level, but also technical and business levels. So I think perhaps one way to try and sway the arguments to your side is to do smaller scale tests and do them earlier to get some buy-in and provide evidence for your proposed designs. This will show them that it is not you, but the potential user's that will have issues with this, and the end result is that the argument doesn't become personal.

And in the worst case scenario, the BAs put in the design they want, you do the user testing and find that it fails (without saying 'I told you so') and the next time they will take your input more seriously.

  • I agree with you, I think you nailed the point about the product owner making the final decision. This was actually what I wanted to approach my management about as we do not have anyone in that position at the moment, we pretty much take request directly from the business. And in my experience, someone needs to filter out the wants/needs and be responsible for the direction and success of this product. Thanks for your input. – Mark Feb 25 '17 at 0:00
  • I guess this means that the business still has to sign-off on the decisions, which means that the BAs probably have more influence unless there was some business decision that requires explicit input from the UX designer. I might just point out that pushing for a product owner might also result in a BA being moved to that position, which means you still have to resolve the issue of getting their buy-in anyway. – Michael Lai Feb 25 '17 at 0:08
  • Get something out to testing quickly. The most compelling evidence is video of users struggling with the interface. – PhillipW Feb 25 '17 at 19:30
  • In some organisation single person perform both the roles. I've noticed that there are huge overlapping points when it some to their job descriptions. What do you say? @MichaelLai, having a PO for signing off is good but it again adds a layer. – Hemchandra Jul 13 '17 at 16:03
  • @Curioussoul Yes, many times I have had to act as both the BA and UX designer in projects, and as you say having a PO for signing off adds an extra layer in the process. I would argue that at least this prevents all decisions about the design being made by a single person, which is likely to be biased towards that person's point of view. Not saying that it will necessarily be the case, but it happens often enough that you want to try and avoid it. – Michael Lai Jul 13 '17 at 23:47
2

What is your design process? If you don't have an open process, you will face these issues.

Even if you feel like it's a charade, get them involved in the ideation session at the start of any UX change.

E.g. host a meeting, get everyone who wants to be involved to sketch out their ideas, then work through them and explain which elements will cause users difficulty, and which are actually go, then amalgamate them.

If you make BAs and their suggestions part of the process, you remove them as part of the problem. You actually turn potential adversaries into ambassadors for your group solution.

Remember what Nielsen says: UX is not an art project, you're not unveiling a grand design. You're going through a series of well-thought out processes to reach the optimal goal for your resources.

2

This happens when managers fail to provide a framework for the team to know where one role stops and another stops, and in my experience it is very common. One idea is to work with the BAs and reach some agreement on the division of labor: they are accountable for defining the problem in a way that is solution-agnostic, and the designers are accountable for solving the problem as defined. An analyst can contribute to great design by making the acceptance criteria clear and unambiguous.

1

It sounds like you're in a no-win situation: from your description, you have the responsibility for the human-factors aspects but the BAs have the authority over them.

No one in that situation can do their job. The authority must always go with the responsibility. That's perhaps the single most basic principle of management, and violating that principle is perhaps the favorite ploy of psychopathic bosses (it's also violated innocently by ignorant bosses).

Either someone above you needs to make you a consultant only (in which case you might want to update your vita), or you need to have the authority to decide how you solve the problems that you've the responsibility to solve.

The BAs should tell you the business issues, and then complain to you only if they can see and clearly explain why your choices are not addressing some part of the business needs. They should not get into the cognitive and social psychology or the visual design unless they have the appropriate training and experience.

0

As a Software Engineer, I'm on the other side of this argument. Before, I worked with the BAs to understand and implement customer requirements. App design was collaborative, but usually one-of.

Then an ambitious BA sold management on the need for UI/UX. It's been nothing but power struggles ever since.

The UI/UX guys try to boil an "app" down to just screens. They know nothing about the data, the infrastructure, what it takes to build the backend and they have zero development experience. They frequently overlook features available in a mobile app versus a website or desktop app. All they do is draw screens and act like it's "their" app, so they are the boss.

The last thing any of us makers need is some no experience prima donna trying to take over.

So my advice to you is this: You are a consultant. It's the BA's job to define requirements. It's the Software Engineer's job to build a professional app. It's your job to help tie those 2 together with screen mockups that satisfy the requirements, and the technical direction, not get pissy if we don't agree with some pretty picture you've drawn.

Think about it this way: If the only way you get your way is by tattling to management, you're an obstacle, not a team member who's in it to make a better product.

  • Many of the UX designers these days come from visual design or front end development background, so I am curious that you have these UI/UX designers basically just wanting to draw screens (and not complain about not enough research being done) :D I have heard of the mysterious UX/BA role going around, and I think you would have to be an ambitious BA or UX designer to do something like that... – Michael Lai Feb 27 at 6:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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