Avoid Problems by Looking Deeper

Somewhere, right at this moment, someone is saying "we need to make this quick change to the application - get on it."

This Way, There Be Dragons...

Beware! THis way, There be dragons...

This is always a pivotal moment, and a sneaky one at that. It always sounds so easy, so reasonable...no trouble at all. But if someone, namely you, doesn't take a moment to think it through you can count on this turning into a sea of problems.

It is the very rare application that is so simple that a change doesn’t impact anything else. For the rest of us, it is vital that you look at the bigger picture to check to see where the change will have impacts beyond the “quick change” that everyone is focused on.

House of Cards, Dominos Toppling...Pick Your Metaphor

Sometimes, whack-a-mole is more than a game.

Listen closely to the discussion about the change that has been requested. Has anyone, really, questioned why it's being requested? Too many times teams run around playing problem whack-a-mole when that simple question, and a few follow-ups, could make it clear that there is a deeper issue and that this change really would only treat a symptom. Often this is a case of "the user asked for it" but it's important to remember that users are able to tell you what they *think* the issue is - it's our job to dig deeper to see the if there's a difference between the symptom and the real cause. But if the question isn’t asked...well, get out your mallet and start swinging.

Or maybe this really is the solution to a problem, great! But by fixing X on screen Y, what impact does that have elsewhere in the system? How about elsewhere in the project?

OK, so you’re ready to move forward adding or changing this functionality, and everyone is on board, so what happens when something doesn’t work as expected. What are the edge cases*? How can this go wrong and how can you handle that gracefully for your users?

Let’s Look at an Example

Let’s say your application is used to deliver goods or services to your customer’s address, and it’s been decided that the address section of your checkout is too limited. The requirement has come down that instead of just 1 street address line, you need to increase it to 3 line.

No problem, right? Easy-peasy.

And you’re right, adding the additional lines to your form to collect the extra address information isn’t a huge job. So what’s the big deal? Has anyone thought about the following and either verified that there is no problem OR come up with solutions:

• Can the rest of your fulfillment system handle the additional information? If so, what are the limitations? For example: how to handle it when those fields are blank, max field size, restricted characters, etc.
• What about your accounting system, are there any issues with the additional data there? 
• What happens when a user puts unexpected data into those fields - maybe they decide to put delivery instructions there, special requests for their orders, or any other non-address information? (Don’t think that will happen? I can promise you it will. I’ve seen it happen, many times—the one thing you can count on is users will do the unexpected.)
• How will you handle users who misinterpret the purpose of those fields? Real-life example: During user testing for a similar form, we had a user who thought they were supposed to break up their address across the 3 lines - street number on line one, street name on line 2, and street type (Drive, Way, Street, Lane, etc.) on line 3. 
• What impact will this have on your validation?
• What impact will this have on your mobile users? Is there some way to minimize any negative impact? 

Take a moment, I’ll bet you can come up with more. Go ahead, I’ll wait…

Back? Great! 

While the possible issues will vary based on the functionality being changed, taking a moment now to look at the possible change(s) in different ways and asking a few “what if” questions will save you, your team, and your users a world of pain later.

Other Pitfalls to Avoid

• Estimates, Timelines, and Deadlines - No, you can’t avoid having these, but you do need to make sure that you don’t sacrifice quality, functionality, or quality assurance (QA) testing *and the fixes to the issues uncovered* just to meet a date. The best way to do that? Test and review as you go, including regression testing, to catch issues early.
• Throwing More People at the Project - This one is a close cousin to estimates, timelines, and deadlines...Sooner or later someone will have the bright idea of “hiring more people to get things done faster.” Problem is, your team isn’t made up of machines, they’re people who have developed a set of skills and understanding of your project, and you can’t just run off to the store and buy more of that. I’m sure you’ve heard the old chestnut “just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month” and you’ve probably rolled your eyes about it. But it’s true. Bringing on new people may be a good idea, but no matter how good they are it will take them some time to get up to speed, and to get there your team will have to spend time showing them the ropes. Starting to see the problem? No? OK, let me spell it out...new people may help in the long term, but they will not immediately speed things up - they will slow things down.
• This Won’t Take You Long - Ah, my favorite! Humans are so funny...anything you have to do is hard work, anything someone else has to do is easy. So, unless you are the one actually doing the work, don’t set the estimate at “no time at all.”

It’s true that the only constant in life is change; but that’s also where a lot of the fun comes from. If you keep a positive thought and take just a moment to think through all the angles before you dive in, you'll make the change, and what comes after, the best it can be.

*Edge cases are the unusual, unexpected, or downright weird ways people use products and services.