As a guiding principle, anything that moves more than twice through the review cycle of requirements generation and prototyping is too complex. Table it or drop it.
In my experience, if you can’t figure it out after two passes, then it’s either a complex issue deeply entrenched in associated processes or systems, or you’re dealing with too many unknowns.
In either case, it waits. The only exception to this rule is a feature or function that is of high importance and high feasibility, as discussed in the Fixing the Enterprise UX Process ebook.
I’ll give you an example from a project I worked on a short while ago.
Introducing The Mystery Messaging Feature
At the center of this scenario was a messaging feature — presented as simple, managed communication between user roles. It wasn’t even part of the prototype, but quickly came up in a sprint planning session where two key stakeholders were in the room.
The spec from the stakeholders, in response to our barrage of specific questions, could be paraphrased like this:
- We need messaging — for evaluators to talk to approvers. But other roles might be involved. They should only be able to talk to each other, but there might be times when they need to talk to other departments. And clients. But only about certain issues.
- It should work like Outlook, except no mailboxes or sending anything. It could be like a comment thread, but not everyone can reply.
- There shouldn’t be a central messaging screen, because it may need to appear on other screens.
- What screens the messaging feature appears on depends on what’s being asked. And we need to notify everyone when a question is asked.
This is literally all the information we got. And I can assure you that all the clarifying questions you’re asking in your head right now are the same ones we asked. I’m sure you’re seeing the red flag lurking here. Anything this wide-open and undefined has no business being a requirement. We didn’t plan on including comment threads on every screen, and we weren’t convinced that doing so even made sense. But since we could absolutely see the need for communication in context, we agreed to prototype it.
Sprint One Review
Two weeks later, we reviewed the prototype. The same stakeholder pipes up with this (again, paraphrased):
“When people log in, they should see a little badge, like on the iPhone, that tells them a message is waiting.”
Oh, a badge. Magically. Somewhere. It’s all clear now. Remember, we haven’t fleshed out this messaging feature at all. There was no plan to have any kind of central “messages” screen; messages were simply comments contextually related to a specific summary.
So two weeks later, our scope has expanded exponentially: we are now building some kind of messaging app, complete with alerts and notifications. Which no one is really sure is necessary, let alone how it might work. So we ask:
“Shouldn’t there be some kind of alert or prompt that a customer sees when checking their status that this is requested/needed? How do we know they’ll bother to check messaging?”
Let’s pause here for a minute. A team of 12 people will each work a minimum of 80 hours to prototype something wildly undefined which will probably exceed schedule and budget. We’re spending almost $70,000 in internal cost based on two simple words: They. Will.
We voice these concerns as thoroughly and diplomatically as possible. We suggest it’s entirely possible that this messaging component is big enough to warrant a separate system and project in and of itself, with the potential to be very time consuming and equally expensive.
But you know the end result: we run the next sprint.
Sprint Two Review
Two weeks later, we’re reviewing again. We now have a messaging dashboard in place similar to Outlook’s approach to email. Threads, filters, address book, the whole nine yards. In the middle of the review session, this gem comes out:
“We’re not allowed to store these conversations.”
“These examples could potentially allow customers to expose details that, by law, we cannot store on our servers.”
So we need three-way communication between evaluators, approvers, and customers, it must include or prompt the exchange of proprietary information, but we cannot store that communication. Which, as you might imagine, makes it more than a little difficult for someone to view it.
A long conversation ensues with no answers. So we pivot and explain the internal cost of pursuing this for another two weeks against the remaining project budget, which we cannot exceed under any circumstances. After much gnashing of teeth, it’s painfully clear this is a black hole of epic proportions.
At the very least, it suggests that a canned process for alerting and collecting missing data needs to be considered in detail, in a way that doesn’t expose the customer or the organization to any degree of legal liability. No small thing, to say the very least.
We collectively agree to table it until after launch of version 1.0.
Speak Up — Or Face the Consequences
Over the past 30 years, I have seen multiple variations of this story play out across a multitude of products, projects, and industries. And we’ve all learned, by way of having our noses broken more than once, is that when something remains grossly undefined after two sprints, it needs to be tabled.
So when that voice in your head pipes up and says this is going to be trouble, listen to it. Voice your concerns clearly, thoroughly and, of course, politely.
One of the best pieces of advice I ever received is that silence equals agreement. If you say nothing, you are not only agreeing that something should be done, you are also agreeing to do it.
The price of that agreement can be very painful for everyone involved.
For more practical advice, download the 91-page e-book Fixing the Enterprise UX Process by Joe Natoli.