One of the most frustrating things to hear as a designer is, “Adding this [feature/function] isn’t going to be that hard; you’re thinking too much into this.”
Are we? Are we thinking too much into this?
Or, have we been burnt too many times by the bravado of someone pushing to implement last-minute product ideas and decisions whilst waving their hand dismissively at the thought that “design” actually involves deeper user and system thinking than what they imagine as 'simply' sketching up a UI or storyboarding their new idea?
For me personally, I’ve got a handful of past conversations that vividly come to mind as if I was still sitting in that meeting room, desperately trying to convince these adamant stakeholders that their seemingly simple idea will exponentially grow in scope and complexity far greater than how they envisioned it... but to no avail. It would only be a matter of time before these customer satisfaction, process, and delivery risks manifested themselves yet again.
However, the good thing about having these painful conversations over and over is that you’ll eventually realise that you have the ability to stop this recurring nightmare. The key to doing so is learning how to express your concerns in a way that speaks to what they value, helps them achieve the outcome that they're after, and be able to demonstrate all this.
Fast forwarding to today
In revisiting a 2017 “What is Wrong with UX” podcast episode by Laura Klein and Kate Rutter titled “Complexity”, their discussion centred around that same issue of explaining what conversations and thought investigations need to be had to know whether a new idea or request is feasible [according to whatever goals and constraints the project has].
In particular, they briefly covered a realistic use case of a product manager wanting to add a single button to their product which inspired me to take that scenario and further explore what happens as a result (see below). I've also written up a set of actionable steps that any team can use to assess the complexities of their ideas based on Laura's explanation of "X Implies Y" testing.
My hope is that the lessons contained within the following fictional, yet all-too-common story will help you and your team have more fruitful discussions around the unseen impacts that a single idea may bring.
Raising THE flag
A [made-up] story of how rushed features and decisions can snowball into time, effort, and budget nightmares…
Marcus is the digital product manager for a hardware store chain and one day he comes into the office with an idea to add a new product review feature to their ecommerce website. His thinking is pretty straightforward, "We’ll get customers to write what they think about the products they purchased and this will both entice new customers to buy these positive reviewed products. It will also help us see which products are getting negative reviews so we can check those against our sales and consider if we need to replace them."
Now, like many eager, confident people, Marcus tells the design and development team that this should be relatively quick to implement because he's seen product review features on other ecommerce sites, so surely it can't be that hard? However, even though there are likely third-party services that can plug in to their website that provides this review capability out of the box, Marcus and team decide that to save money, they'll just implement a minimum 'viable version' of it themselves.
So, the product team does some discovery research around who would be the target users of this review feature, both the customers writing the reviews after purchasing and the customers who'd be reading the reviews before purchasing. With this research in hand, they're now looking to identify all the functionality that needs to be implemented to provide value to their target customers.
What the product team then determines is that, at a minimum, customers will need to be able to write a review, submit their review, and see the aggregated reviews from all customers. And, since the team recognised that humans make mistakes, they agree that it'll be best to make it possible for customers to edit or delete they're own reviews too.
Marcus the product manager checks in again, thinks that this set of functionality will provide a satisfactory minimum viable solution, and decides to scope their first feature release around only providing these basic write, edit, delete, and read capabilities.
As the product team gets to work, they do some research into what kinds of products reviews are left on other sites, and sadly, they come to remember that not all humans are good. In fact, some people can be downright hateful and perverse. This becomes a potential issue for their hardware store because what if these kinds of people use their new product review feature to write offensive or malicious things? This kind of insight doesn't usually come out of typical design testing as participants are screened and unlikely to spout hate in front of a test moderator. So, if the product team hadn't taken a moment to imagine all the ways that their new feature might be misused or what edge case needs might arise, these consequences might not come to light until it's released to the public.
After hearing about their 'What If' scenario findings, Marcus throws out another idea: "Let's allow customers to flag a whether another customer's review is inappropriate or offensive. I've seen that before, it's just a little flag icon that people click to report a comment. Add that to the next sprint."
And the downhill snowball begins forming...
What's just transpired is a common and often colossal oversight: individual little decisions and features like a reporting flag might look easy, but there is a raft of process, permissions, and platform complexity that come as a result. It's more than a button on a screen.
The snowball continues to build upon itself as the product team now tries to analyse what it'd take to support this little flag; operational support and new technology needs start becoming obvious if this reporting feature were to be implemented in a way that customers expect. The first thing that would need to happen when someone's comment is flagged for review is it being sent to a moderator at the hardware store who needs to then read over it and decide whether it needs to be removed or allowed.
Another layer on the snowball is that when the report comment flag is clicked, the UI needs to acknowledge that their report was recorded so some kind of success message is needed. Not only that, but the product team also needs to now decide if a reported comment should remain visible to the public whilst the review is pending. They do make a scope decision though to not attempt to capture the customer's reason why they thought another's review was inappropriate or offensive.
So, to support this product review flagging feature, a notification system needs to be in place to capture and remind moderators that there are flagged comments awaiting review. Buying or building this will take time and funding away from other initiatives that the product team would rather spend it on. All the functions and integrations will need to be implemented for this to ensure the moderator can perform their moderator functions like approve, deny, edit, show, remove notifications, reset flags, etc. Someone will need to design and code all that.
Additionally, to know whether to approve these comments or not, someone in the business also needs to write a set of policy criteria to help moderators consistently make reviews. And as the business is unlikely to hire a brand-new role just for someone to moderate product reviews, being a moderator will also likely fall onto some other team member's shoulders - further making it hard for them to successfully perform their main roles and responsibilities which comes with its own opportunity costs.
And what about moderator permissions? Surely the business won't want any employee making moderating calls, so a permission system will need to be both written and implemented too. Finally, to even know how to begin being a moderator, somebody will need to write set of employee training for those taking on the moderator responsibility and then that training will need to be delivered and undertaken by those staff.
That small feature snowball is now a thundering boulder, crushing everything in its path.
Delivery dates are pushed out. Budgets are overspent. Other departments in the business now have new tasks on their plates that they didn't expect and, to put it lightly, aren't happy. The team is exhausted.
Why?
Because an idea for a feature was made without giving due consideration of the design and process work needed to consider the complexity of their decisions and the impacts that follow.
All in all, to enable one new feature, dozens of decisions, systems, efforts, changes, and costs followed.
What did we learn?
For one, when we talk about “designing” a product or service, we’re implying that there are far more decisions to be made than what customers see on a screen. As Laura Klein put it, if all you did was draw a feature on a UI sketch without determining all the tasks, actions, and dependencies that that feature implies, you haven’t “designed” anything, you’ve only drawn a picture of a system in a particular state.
Furthermore, when we rush to make process decisions or implement new ideas without giving both everyday and edge cases due consideration, we leave our teams open to a world of last-minute scope scrambling and half-baked implementations that negatively impact not only our customer experience, but our staff's experience as well.
What can we do to prevent this?
Go through your user stories, storyboards, prototypes, journey maps, or whatever it is that you use to capture opportunities and ask your team the following for each idea:
What led to the system being in this state? What other states and needs will implementing this idea necessitate? What might be next?
What outcome does each interactive element or executed task imply?
What actions need to be performed by a user, system, or someone behind the scenes to enable those outcomes?
For each form or piece of content, what will it take to create, maintain, and manage them both now and in the future and who will be responsible for that?
Now knowing what it takes to support all the above, is this idea or opportunity worth pursuing at this point in time?
In summary
When a new idea or decision is brought to the table and there's a push to implement it straight away because it's deemed as "simple", encourage the team to meet and play the "What If" game. Spending 1 hour on that will both help you determine the true scope of what implementing X entails and potentially avoid weeks to months of effort and opportunity costs due to unexplored implications.
Your budgets and backlogs will thank you.
This article was originally published on 14 Jan 2020 and later revised on 18 May 2022 on my LinkedIn page.