Guidlines for UX teams working from a use case document

Question

I am trying to resolve an issue here:

The business analyst team here are adamant that the use case document that they write (including some wireframes that they've done) should be used as a template guide for the UX team - point by point (ie.1. user puts in phone number, address 2. user does this 3. user does that),in how to design the wireframes for a project i'm working on for a firm.

The UX team have the opinion that the use case document should be a document to be interpreted by the UX team to reach the desired solution. as apposed as being followed down to the letter. In other words, we feel that we are having our creativity and analysis skills squashed.

anyone have any thoughts on this?

Answer 1

I think it should be a collaborative task, the analyst has a depth knowledge about the requeriments and the UX team has a depth knowledge about the user and user interactions, so create the wireframes take in account both opinions.

If the analyst has already created some wireframes, take these as reference, it could be very useful to understand what they want or what they think, but not as limitations. The analyst should be open-mind to any way to improve the interface.

Answer 2

Your business analysts are currently doing the product design by proxy. Use cases are supposed to be a way for the business side to identify and communicate the product's business requirements to the design side, who then does the actual product design to meet those requirements. Use cases are not supposed to be a point-by-point description of the product workflow: the business side should certainly not be designing wireframes(!) -- that level of detail is clearly outside their (presumed) area of expertise.

So, you're right, they're wrong. Knowing that doesn't actually help solve the problem, of course.

This is a structural / territorial problem within your organization. Currently, they're the ones defining the product, and you're the pixel-pushers whose job is to make it look pretty.

This might be the result of unusually weak leadership on the UX side, unusually strong leadership on the business side, or both. It may be that your UX team really is mostly a graphic design team, and lacks the skill or or experience to take control of the full design process; or it may be that the business side just doesn't understand or respect the value of product design skills. Probably it's some combination of all of the above.

There's no easy solution to this, unfortunately: being correct about the fact that they're overstepping their bounds -- which you are -- won't actually get them to stop overstepping their bounds.

Pushing back with phrases like "you're squashing our creativity!" is highly unlikely to be successful, because it feeds directly back into that narrative of designer == pixel-pusher (to the average non-designer, "creative" is code for "unserious" or "frivolous"). You're also unlikely to get very far by telling business analysts that your analysis skills are important -- to their ears, that'll sound like you're trying to step into their territory.

Instead you need to find a way to demonstrate your skills, in a provable, measurable way, so they can see that a workflow designed by someone whose expertise is designing workflows is superior to a workflow designed by someone whose expertise is identifying business requirements. An A/B test comparing a strict-by-the-numbers workflow designed by the business side to a UX-designed workflow might sound tempting, and might even work -- but it's a highly confrontational solution, which may cause them to dig their heels in even further regardless of the results. The real solution is likely to be a more incremental matter of closed-door discussions, reaching out to allies in upper management, and building leadership and authority within the UX team.

TL;DR: someone on your team needs to get a lot better at office politics, fast.

Answer 3

A good design is to help users accomplish their goals. Everyone has their own opinions about how things should be designed, but how do we know what's the best for users? It will be inappropriate to take someone's design as a tempalte guide without futher discussion or validation. You may discuss with the analyst about his design concept and see why he thinks about the solution will fit users' needs. This might be helpful to generate a better solution.

Answer 4

Nobody should be coming up with just one idea that becomes the design. Ideally you should be exploring multiple ideas (as many as you can think off) before deciding on the design direction, and perhaps even running with 2 final ideas that you progress via A/B testing to see which one is best.

So just treat their suggestion as just one idea and see how many more different alternate ideas you can come up with. Your design goal is to solve your stakeholders business problem and to make it effective and efficient for the user to accomplish their goal.