This is perhaps the least “sexy” piece I have ever sat down to write. In fact, I am surprised that you have made it to this second sentence. But, today, as I looked through my list of posts I’ve been meaning to write, this one stuck out to me, and thus I felt it was its time to shine.
For the past several months, I have been noticing a puzzling trend happening in the world of software development. Perhaps this has only been happening in my own bubble, but since it has been happening so often, I assume it has been seen elsewhere. That trend? That of the business team not wanting to take ownership of their requirements for a project or product. Not only do I see them not wanting to take ownership of the requirements, but they don’t even do, think about or have goals in mind for a project. To make things even more puzzling, the business teams have been looking to me, as the UX person, to define and maintain the requirements for the system.
Why does this seem so puzzling? Because instead of taking the opportunity to define what a product needs to have to solve their business problem, business team are basically saying to me “I have no idea the purpose of my product. I just think something that does something really cool like Pinterest would be great.” Then they want me, the person designing the solution, to come up with the problem.
If you are a UXer facing this situation you may be thinking a few different things. First, you maybe thinking “Lis who cares?? They are letting us define things, and we know best anyway!” OR you maybe thinking “Lis… right on!” OR you may be thinking “How weird is that?!”.
For those of you that are saying “right on!”… thanks. For those of you saying “this is weird”… you’re right! For those of you saying “Lis who cares??” my answer is you should. Why?
Because even though it is our role as UX designers to help facilitate the process of understanding what should be done on a project or with a product, when we get to the point of the business team handing UX the responsibility of defining the entire product without understanding their input, we have a big problem.
Don’t get me wrong. I am not a fan of large requirements documents just for the sake of having something written down, nor do I think that requirements have to be formal enough to catalog in the Library of Congress. I do, however, think that the intention of the product should be recorded and upheld, because if it is not… how will we know that we solved the problem correctly for the business as well as the user?
Requirements are the “what”. They define what the product should do. The outputs of our solutions are the “what” extended with the “how”. Think of it like a test. The “what” are the questions on the test, the “how” are the answers. If you have the person taking the test writing the questions to that test, they are always going to “do well” on it, and no real progress and learning is ever done. Thus, businesses, if you have the people taking the test (I.e. The UX and design teams) writing the questions for the test (I.e. The requirements) you’re going to get a “successful solution” no matter what, and probably no real value added to boot.
Put more frankly, someone needs to be responsible for defining and maintaing the business purpose behind the project, and that someone should be from… the business!
If you are facing this same trend and agree that it is a problem, you may want some quick tips on how to combat it. Well there are a few that I have been using that have helped.
First, I really try to utilize my facilitation skills to help my business teams figure out requirements. When they turn to me and ask me to write requirements, I tell them I can’t, because it is their job to tell me what they need. I then use my UX know how to get them there.
Which brings us to tip number 2, putting the requirements back on the business. Encourage and enable your business partners to take ownership of what they need and not of the solution. The solution is yours UXers! Take ownership of that, and keep asking the what from the business.
The last tip I have is when a business person asks you to, for example, make something like Pinterest, always ask “how will we test that our solution meets requirements?” or “how will we know we were successful?”. “Will that be a design test, color palette, functionality?” And then ask “why does this need to be like Pinterest? How does that help the business?”.
The outcomes of implementing these tips are a more engaged and responsible business team. The business team, however annoying, is necessary for balance within our companies. They help to make our company more successful from a different angle, and we need to partner with them in order to create a holistic product that means user AND business needs. By helping them to be more engaged you are helping yourself get the requirements and business insight you need in order to do great work that is for both the user and the business. That is one way UX adds real value.
Many business are happy to take ownership of their requirements when provided with clear directions from our part. For most projects, good facilitation during a kick-off or workshop seems to be enough.
I’d love to experiment with having customers completing a Business Model Canvas or equivalent for their project (http://www.businessmodelgeneration.com/canvas).
And then from that point working together on some kind of Product Canvas (http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas/)
Business Model -> Their responsabilities
Product Canvas -> Conjoint work
Really cool ideas! I’ve worked with clients on completing the Business Model Canvas, but love the product canvas as a way to couple work. Thanks Xavier!
The chief consumer of requirements is QA. They need to be functional requirements, which UX isn’t really suited for.
PM’s write those as the rote requirements that devs build and then QA check off.
Of course most web places don’t do real QA, at which point the requirements would then still have to be checked off by the developers, and they don’t consume UX style requirements. Which means the UX person would have to write them as a PM, and that’s outside the bounds of what a UX person should or can do.
It’s a stretch.
Great post, Lis. I sure wish we’d had more folks sign up for my workshop way back when. Perhaps now is the time?
I’m so glad you brought this up! I was sure I had talked to someone in depth about this before and I couldn’t remember… but now I do :-). Considering the responses that I’ve seen, now might be the perfect time. I’ll def bring it up!!
so true Magga! I have also had this experience with client management teams inside agencies… they didn’t know to get the requirements from the client and looked to me to provide them instead.
Thank you for bringing this up, I have been wondering about this myself.
For those in the agency world, please read the above and replace ‘business’ with ‘client’. This issue becomes even more painfully obvious in that setting.
:)Magga Dora