The Dangerous Watermelons 🍉 in your Software
Watermelons 🍉
They are green on the outside, and red on the inside.
A watermelon in software is when you have a feature, but there's a workaround, another workaround, then another workaround which is some warning that you have to ignore, then another workaround and then the feature works. Then you have another feature after it, but it doesn't just work, there's another workaround, and this one is undocumented, then there's another workaround, which is some setting somewhere that you don't know you need to set, and another workaround, and then the feature does work. But your task isn’t done yet! There's another feature with another workaround, another workaround, and that workaround is kind of like rolling a D20. When you roll it, if you’re unlucky, you lose all your work and you you have to go back to the beginning. But, if it does work, then yeah cool you can keep working, but there's another feature after it with another bunch of workarounds.
That's a watermelon! It's green on the outside and red on the inside.
Watermelons usually consist on the inside of:
Confusing Warnings
Undocumented Behaviour
Hidden Settings
Unresolved Bugs
So when you ask someone: “Does the software work?”. They will just say: “Yes it does.”. Because on the surface level, it does:
And they are technically correct! It is really important to consider that they are technically correct. Do not argue about whether it works or not. it is an endless rabbit hole of discussion. Conversations like: “Does it really work? What is considered ‘works’? It technically does, there's just a lot of workarounds to make everything happen, but it works!”. If you keep discussing that topic then you will eventually just land on the age old argument of: No True Scotsman. What would a True Scotsman do? What really constitutes a working feature? It is an infinite discussion.
If instead you ask: Is the workflow good? And you sit behind the user as they do the work, then suddenly you will see all these workarounds. You will go “What?! How did we not know about this?!”. I’ve seen this happen at so many companies.
So why do users say it works, when it can be annoying, awful, or downright painful to use? Why do they say it's all green even though there is a whole bunch of workarounds underneath? They usually say it works because they:
Have deadlines
They have work to do! They don't really have that much time to complain. They got stuff to do and, well, they can do it. It's just really painful, but they'll do it.
Expectations are low
They keep getting fed software that just doesn't work well. They are used to it now. Yeah the software doesn't work well, but it's kind of how it goes, so they will stop telling you when there are a lot of issues.
Don't want to look needy
They don't want to be that person that keeps asking for better software. The squeaky wheel gets the grease, but also, the stake that sticks up gets hammered down. Ask too many times, and there might suddenly be a target on your back.
At some point an engineer will say: “Hey, it works, you're just bad at your job.” which is incredibly dumb thing to say, but really does happen. Why is it dumb to say? Because Don Norman already cut that down to size in 1981, which is 44 years ago. I'm talking about Don Norman, who wrote the “Design of Everyday Things” book, that Don Norman. He wrote an article called “The truth about Unix: The user interface is horrid” in 1981.
In there he has this section where he goes over some of the command line functions. So on the left is the function, and on the right is what you have to type to activate that function.
And as you look through that image you see that many of the command names do not quite make sense. Why are some 2 characters, and other 3 characters, and then others 4 or more? It is confusing.
But then the weirdest one is at the bottom: Search file for pattern, which is grep.
grep!
Why is it grep? Because it stands for: “Global REgular expression, Print”. GREP. Again, this is technically correct. Again, do not argue about whether this is named correctly, as it is an endless rabbit hole of no true scotsman. You're just stuck discussing forever into infinity. So when you look at something like “Global REgular expression, Print” really what we can see is what Don Norman said, which is: The user interface is horrid. Which means that the user experience is horrid. So when you ask someone: Does the software work? Yes it does, but the user experience is horrid.
It's a watermelon 🍉.
How do we fix this?
Usually what people then say is: “You know what we need? A better ‘definition of done’ or better ‘acceptance criteria’!”
Ah yes. More meetings. Surely that will resolve the problem this time. We'll just have more meetings discussing what exactly the definition of done is, what exactly the acceptance criteria should be, because that hasn't worked any other time, but this time it'll work!
No. Again, don't argue about these things. They are rabbit holes of discussion, and of no true scotsman. You're going to get stuck in endless meetings.
You know what you can't argue about? Sitting behind a user and watching them work. Like literally seeing someone use the software! You actually sit behind them as they do the work, and you look at them, and your brain will automatically think things like “Oh, that's really confusing. That's really difficult to do. Ah, this needs to be improved.”. In a user test you will find what the actual reasons are for the watermelon to exist. You will find out if the software is actually good. If the software can do what it needs to do, when it needs to do it, to the quality that users want it to, and in the time they want it to happen.
Don't just ask your users those questions. Do not just communicate with users via surveys. Again, if you ask someone: “Hey, does the software work?” You are going to hear: Yes it does. Which is technically correct.
You are missing the watermelon underneath the surface. It doesn't help you much. Instead, you have to look at users who are using the software. Do actual user testing. Sit behind them, watch them work, actually see what they're doing.
Steve Krug talked about this a lot in “Don’t Make Me Think”, a lovely book that I highly recommend. One of the things that I personally took away from that book is that, yes, you can do surveys, if it doesn't stop your user testing. And you can do automated testing, if it doesn't stop your user testing. You can have product owners and product managers, if it doesn't stop your user testing. You can be agile and you can do do iteration, if it doesn't stop your user testing. Above all else: If it doesn't stop your user testing. If you do any of those other things, and it limits how much user testing you are now doing, then it is probably not the right way to go for you. You can do those other things, but do not limit your user testing to be able to do them. You need to make sure you are always user testing, because the only surefire way to prevent watermelons is to user test.
So when it comes to watermelons, the takeaways are:
To find 🍉 you have to sit behind a user and look at what they are doing.
Actually sit down and see what is happening. Do not just send surveys or NPS questionnaires.
To prevent 🍉 you have to user test before marking a task as complete.
If an engineer is working on a task to make some software for a user, and if the engineer says that it works: Great, have you tested this with a user? Has a user run through it without confusion? Has a user said “Yes, this is good.”? If not, then the task is not complete.
Do not stop your user testing. Ever.
Thank you for reading! If you enjoyed this post, you can find my talks here, and my other posts here. You can also subscribe below to get updates when a new post is published. There is also a video version of this article that you can find below.