Designing for 'what-if' scenarios: here's what I've learned

Process & Techniques
#1

I’m a senior UX with about 10 years experience and I’ve worked on lots of projects, large and small, some worth a few thousand, some worth a few million.

One thing I run into time and time again is the handling of ‘what-if’ scenarios. I’ve learned that you need to design for them.

But it’s not ‘if’, it’s ‘when’.

Here’s my advice:
Find out if the what-if scenario is actually a user need. It might not be.
If it is, get the basics right first, then add in the what-if scenarios. Without a backbone interaction working well, you have nothing.
Do not design around the what-if scenario. This will kill your project stone dead.
Weigh up the impacts of designing for the what-if scenario: does it make the main use case harder? Does it have no impact?

Anyway, share your thoughts!

3 Likes
#2

Love this! I wish I had more to add, but I do love this.

#3

I love this to – for two reasons.

  1. It’s so cool to see someone proactively sharing helpful ideas and making others think.
  2. I agree wholeheartedly. It concerns me when people design based on assumptions and it’s unfortunately all too common.

In my organisation we have a ‘rule of 3’ rule. A what-if isn’t a problem (and therefore it doesn’t need fixing) unless 3 users mention it. Otherwise you’re wasting time and resources.

1 Like
#4

Do you have the IT knowledge to answer those questions from a back end perspective?

If the software is well coded, any what ifs should be easily developed later on.

I dont know how many projects Ive run where Ive done the business requirements including the UX and UI. Client has signed off. Ive built it, they have come back and said “What if it could do xyz”.

For me the way to mitigate that risk is to use really robust but flexible software environments that can be manipulated to take a front end change on a whim.

If we just talking web pages, thats pretty obvious, just build to what the client wants right now and worry about the future when they ask for it.

#5

I’m not really fixated on the software side, although if an interaction is needed but hard to build, it has to be sidelined, but that’s after we’ve decided there’s a need for it.

#6

Another team built an interaction that fixated massively on a fringe edge case. When they tested it, no one could use it.

That error in judgement cost god knows how many thousand £

1 Like
#7

I really like these tips. How would you go about validating if the what-if scenario is worth investigating? And then how would you investigate it without veering away from the main design objective?

1 Like
#8

Main design objective needs validation too.

Anyway, good question.

In a recent project we built some designs that included the what-if scenarios. It became immediately clear that users didn’t need or like them. So we dropped them. The interaction we have now is substantially simpler.

How do I know if it was worth investigating? I didn’t think it was worth investigating, in fact I thought the what-if scenario was needlessly complicating the issue but the business were very adamant it should be in the design. You’ll find that a lot of UX is dealing with political pressure and its how you deal with this that is key.

#9

I’ve learned that you need to design for them.

I agree, it’s good to design for some arising questions that might come from team members to nip it in the bud ASAP. I’ve seen how these could turn into monsters if not done early and swiftly enough.
I also think what-if scenarios are just a sign that the overall UX vision is not clear enough or something isnt being articulated- either in the planning or research stage. I get that sometimes the CEO, for example, will chime in with an ‘unthought of’ scenario but in such situations I think if the UX vision is clear and the UX leadership is strong, these what-ifs shouldn’t even see the light of day, however sometimes it is necessary just to do a quick mock to show that it wouldnt work.

1 Like
#10

aye, agree

1 Like
#11

At my current company there was a history of not considering of all these what-if edge cases and there were times it came back to bite the company in the ass and cost them more dev time to fix.

To mitigate this, we have now moved to BDD (behavior driven development) and this involves design/product working together with the devs and QA to think of all these what-ifs ahead of time and write scenarios that feed into the QA tests. Literally just moved to BDD recently so can’t say for certain if it has helped, but it definitely seems like a solid enough approach.

2 Likes
#12

I’d love to hear back on this in the coming months. Sounds like a super interesting change.

#13

there’s a difference between edge cases that expose bugs and scenarios that mean whole different interactions; my post was about the latter.

I guess, at a wider level, you can categorise what-if scenarios into the following four types:

1)High probability, high impact: super important, design for these
2)High probability, low impact: keep them in mind, but don’t get distracted by them
3)low probability, low impact: don’t design for them, ignore
4)low probability, high impact: uh-oh, you’re dangerous!

its class 4) that I’m talking about

1 Like