Thank you for sharing the before and after requirements docs – most helpful and illustrative.

Your historical analysis, human nature and business pressures analysis, and explication of how teams typically work, in your deconstruction of the problem phenomena was superb. Really demonstrates your depth of clarity and experience.

“Learning how to deal with badly written requirements is part of our job, but they can be a trap for the designer. How can the user experience designer handle the inevitable dysfunction that badly written requirements create in his or her relationship with the business analyst?” <– The real gold!

"They became skilled at decomposing and diagramming processes – swim lane diagrams, workflows, and, yes, spreadsheets full of requirements." <– Utterly spot on.

In fact, these artifacts are the meat and potatoes of the typical BA, and the work product they are most proud of, and through which, how they perceive that they demonstrate and prove their value-add.

As a DBA and DB Dev (and former front-end developer who marvels at the work of talented UX designers), when reaching out to a BA on a project that is suffering from "technical anomalies", always ultimately caused by the dysfunctions the article describes, the BA typically proceeds to hand over to me their swim lanes, spreadsheets, and printed stacks of email threads.

I always cringe inside, and after I allow the BA to take me through their works of art and precious children, sucking 45mins from my day, I inevitably say something like this;

"You are aware that the problem here is the way the front-end devs have implemented the UI, which is causing the users to double POST. To make matters worse, the devs have improperly implemented their roll-their-own database transaction handling system in the middle-tier along with their business logic, compounding the whole problem.

You do remember that I told you to suggest to the devs very firmly that they call into stored procedures and simply pass parameters around off the query strings or posts?

Did you work with the design team on this UI?

Did you speak to the devs like I asked you to and firmly tell them to use Stored Procedures, and to not do their own database transaction handling?

What did the designers recommend? Why wasn't it done? Why are the devs doing exactly what I told you would cause you and I pain, suffering, and late nights?

Why weren't any of these issues addressed prior to now?"

The BA inevitably stares back at me non-plussed, and turns my attention back to their swimlanes and excel requirements tracking matrices, and tries with desperate passion to convince me that all the answers are in their stuff.

@Jill – "working with Project Managers to identify activities needed to be built into the project schedule in order to develop well articulated business requirements that reflect the voice of the customer" <– as a very high-level theoretical best case, I suppose it is impossible to not agree with this statement.

That said, the "voice of the customer", whatever that means, should be properly understood as belonging to and representative of all participants in the dialog between end-users, BAs, designers, business managers, software devs, and the DBAs – these are all the real "customers".

The fundamental lack of awareness among most IT shops of the interdependent nature of the complexity that is application development, coupled with a general lack of appreciation for the interdependent nature of each given team member's work product upon each other team member's work product, is the chief cause of the dysfunction the article seeks to show designers how to better insulate themselves, and the final product, from.

@Octavia – "The business requirements are the design – it is just not clear what the design is." <– I agree, but with the following commentary: the problem with the requirement statement you speak to is that it conflates a functional requirement, "make user aware of X", with how to implement that functional requirement, "display an Alert box".

As you say, display Alert box as the UX/UI implementation of the functional requirement that "the user be told something", does not provide adequate detail for the designer.

The actual difference between functional requirements and how to design and implement those functional requirements, the difference between business logic requirements versus the technical design requirements, and the difference between the technical design and the technical specification which details how to implement the technical design, are all differences that are hardly well understood and fully appreciated – even by folks who have done this work for a long time.

Conflation and misunderstanding of these differences and artifacts is wide-spread, and goes a long way to causing most of the trouble and frustration that everyone in the drama, and the end-users most of all, suffer from.

It Works Like This ::

The designers are left asking themselves what the requirements "actually mean", as while best case the functionality desired may be clear, there is precious little to guide them in the implementation.

The end-users don't understand much of anything about this stuff, and just wish that things weren't so difficult to use, and that the UI wasn't so complicated and counter-intuitive.

The devs just wish the BAs actually knew what they were doing, and that the DBAs would stop their monotonous harping and tireless advocacy of Stored Procedures Everywhere.

The BAs wish the devs would just do what they're told for once without whining and complaining, and wish that the end-users weren't so retarded.

The DBAs just wish the devs weren't such loose cannons, and would at least attempt to use stored procedures once in awhile, rather than playing fast and loose in the middle tier.

And at the end of the day, the poor BA seeks often seeks out the DBA, because we are usually the most even keeled emotionally, and crys on our shoulder, and tells of the travails that no one else seems to understand, how impossible their job is, and how hard they work for their $85k – $125K salaries.

And often later than anyone else, the DBA leaves work, gooes home, and late at night writes long article comments trying to tell everyone on the internet what the real situation actually is. ;+)

@Stacia – "At my job, UX designers and BAs work side-by-side…we’ve evolved (over 4 years) into a checks-and-balances system
Some new BAs have trouble relinquishing control…" <– Where do you work? Are they hiring DBAs???

At my job, UX designers and BAs work side-by-side…we’ve evolved (over 4 years) into a checks-and-balances system. Our respective documents should reflect each other’s talents, and when they don’t we compare and seek the best solution.

Some new BAs have trouble relinquishing control, but once they realize that we do half their analysis, and do it well, they are happy to work closely with us for the length of the project.

My company Brain Logic works in a similar space as Industrial Wisdom. We focus on working with Project Managers to identify activities needed to be built into the project schedule in order to develop well articulated business requirements that reflect the voice of the customer.

So glad to have someone else educating on the benefits of this approach.