How To Get To "It Just Works!"
Back Story
At time of writing it’s just over ten years since I co-founded the SaaS startup clearreview.com - an HR Performance Review tool, used by companies from as few as 25 employees to as many as 20,000.
I was the CTO. I’ve always brought a huge product slant to my tech leadership, and this situation bears witness to that.
In the words of the then-CEO, my “laser focus on user experience led us to build a sticky product that people genuinely enjoyed using, resulting in high levels of user adoption - a high bar to achieve in the HR tech space where products often struggle to gain traction.”
So many users, so often: “It just works!”
So how did we get there?
There are a few parts to this.
Team Attitude
Firstly, your entire team needs to understand the need to focus on the actual working life of the users. From product through tech through testing. All of you on the same page. Know the user. Understand how they’re feeling at the time. Ask yourself WHY they are using this new feature and what their unconscious success criteria and pain thresholds are. More on this in a later section.
Start by knowing this truth:
The user already hates us
“The user already hates us,” was my opening line for each new developer we onboarded. I’d go on to explain: The first each new user hears about us is when an email from HR arrives saying ‘oh hey wow we have a new Performance Management Tool - Please log in as below!’
This is guaranteed to wind people up. Another system. Another login. More performance reviews. “Oh just **** off.” I can actually hear them saying it.
So, I would then explain to the perplexed new developer, if in every single interaction with our system, we are a little less annoying than they expect, and a tiny bit more helpful than they’re anticipating, and we repeat these tiny victories over each one of our dozens of features, we have won. Simple as that.
It sounds obvious but apparently it isn’t. Just aim to slightly delight them, a tiny bit, with each new journey added to the system. The net effect will be very positive.
As our repeated “it just works!” feedback can attest.
But it takes more than focus and intent. How do we ensure that every feature actually does this? Read on.
The Development Lifecycle
The Story
It all starts with the Story. Much has been written about the “well written Agile story” so I won’t cover that here, but as a brief checklist the story must be:
| GOOD ✅ | BAD ❌ |
|---|---|
| A single behaviour | Not a snowball |
| A visceral desire of the user | Not just an instalment en route to a pre-envisaged product |
| Small enough to take only a few days of work | Not an “iceberg” of hidden complexity |
| Explicitly framed | Not a rabbit-hole of implicit product expectations |
.
On top of this, the “so that” aspect of the story - the WHY - must be absolutely clear. This will help us not only to prioritise the story effectively but also give us some clues as to what the overall experience of the feature must feel like and - ultimately - ALL of this comes down to feelings. So this aspect of the story is crucial.
Bad Story ❌
So, you want to avoid this kind of thing:
“ I need a search box on my Employees screen so that I can find people easily”
This is basically saying “So that I can find people, I want to find people”. Tells us nothing useful. “I need the thing because the thing”. Not terribly useful.
This kind of story is also likely to lead to a very transactional experience for the user. Stories framed like this often result in experiences which are coldly designed “from the database outwards” and this is always a sure route to a terrible user experience.
Good Story ✅
“I really need to find an employee when I only know part(s) of their name so that I can quickly open someone’s file when I need to”
OK, so this gives a bit more. It’s also A LOT MORE like something that would actually come out of a real user’s mouth. The “bad story” version just feels like Feature 1,612 in an endless system build.
The “good story” is something that may just actually improve a user’s life, for a few seconds. Remember: If you don’t begin with the Value, then it won’t achieve that Value.
“It just works” is the whole point, remember?
OK, so we have a worthy story which paints a vivid picture of someone’s frame of mind at the point of need… Let’s plan it!
Parallel Realities
So we’re going to look at two different ways in which this might unfold from now on. These are:
- Reality 1 - Planning focused solely on technical planning (bad)
- Reality 2 - Planning focused solely on Customer Scenarios (good)
Read on!
Reality 1 - Planning focused solely on technical planning
The first version of reality, “Planning focused solely on technical planning” is how many teams approach this. It’s such a wasted opportunity. You’re in Sprint Planning / Story Planning / Whatever You Call It; you’ve got a product person, the dev team, maybe a designer, maybe the CEO has dropped in. It’s a veritable melting pot of ideas and differing psychologies.
So USE them! But instead of this, what tends to happen is the story is pulled in, and the tech leads / most vocal devs jump in and reel off a list of tasks:
- Add indices to those first name / last name columns in Employees table
- New view setup in Employees app
- Text box for input
- Handle mid-word searching (e.g. searching for ‘mit’ returns all the Smiths)
- Show number of returned results on the screen
I guarantee that you lost the interest of the non-tech people by the end of the second point. So not only do you have a very uncertain experience on its way - just a bunch of technical moving parts - you also totally failed to capitalise on the brain mix in the room! This is sad.
I’m sure you’ve worked with many situations like this before and at the time it probably seemed like progress, but I challenge you to say with any conviction that your users were hands-down delighted with the results.
So let’s take a look at Reality 2 instead now…
Reality 2 - Planning focused solely on Customer Scenarios
So first off, we do NOT jump into technobabble. (In fact, I ban technical discussions from these sessions; not even the devs are permitted to talk about implementation details at this stage).
Desired Qualities
No, we start with a very important, very human question: What are the Desired Qualities of this feature?
Re-reading the story…
“I really need to find an employee when I only know part(s) of their name so that I can quickly open someone’s file when I need to”
This says to me the main Qualities of a successful implementation would be:
- Quick
- Works as you work
- Minimal waiting
- Clear disambiguation
So straight away that’s going to help us make some key decisions with confidence, and also provides a checklist of constraints to guide any unexpected design / operation questions we may hit later in development.
Scenarios
This is where the magic really happens. Our output from this session is a series of “Behavioural” scenarios which describe the features in classic “Given, When, Then” syntax.
Sticking to this format not only allows our scenarios to be consistent and uncluttered, you can also take the output from this planning session and plug it directly into any number of behavioural testing tools.
So THEN, bonus point, your tests will ACTUALLY match your expected feature which - when added to the reliably quick CI pipeline you doubtless have which runs each of these tests before any deployment - also guarantees that the thing will work as expected in perpetuity.
Anyway, let’s write come scenarios. This is something anyone can join in with, and you should encourage everybody - ESPECIALLY the non-tech folk - to pitch in here.
Scenario: I can search on any part of a name
- Given we have employees John Smith, Priya Patel, Joan Smith
- When I enter ‘mit’ in the search field and hit enter
- Then I see only John Smith and Joan Smith
- And I see “2 employees found”
Scenario: I can enter more than one term and if I do, each result should contain all of the terms (i.e. more input = fewer results)
- Given we have employees John Smith, Priya Patel, Joan Smith
- When I enter ‘oh mit’ in the search field and hit enter
- Then I see only John Smith
- And I see “1 employee found”
Scenario: End spaces and spaces between words should be stripped out
- Given we have John Smith, Priya Patel, Joan Smith
- When I enter ’ oh mit ’ in the search field and hit enter
- Then I see only John Smith
Scenario: If no records match then I want to see a polite message and an empty result set
- Given we have John Smith
- When I enter ‘foo’ in the search field and hit enter
- Then I see ‘No employees match your search’
- And I do not see any employees
- And I do not see “employee found” or “employees found”
Now. Pop back up to “Reality 1” above a second and picture what might have been delivered as a result of that planning session.
Then re-read the scenario titles above and KNOW (because we turn these into tests) that this is exactly how the thing will operate.
It’s a very powerful way to declare the behaviours of your application.
Plus, in this second version of events, nobody is in any doubt has to how the feature works. All implicit expectation has been removed; we are all working on the same thing.
In comparison, our Reality 1 is virtually guaranteed to result in differing expectations as to what the thing will do when delivered.
Writing these Scenarios as a group of different minds also means that we have already bridged the human gap for this particular story, and we haven’t written a line of code yet!
We have also ensured a much more ’luxurious’ user experience and avoided that ‘unfinished’ feeling which many new releases often have.
Conclusion
So, in summary, we have:
- Focused all tech people on the value of small delights in each feature
- Written a story which represents a single, visceral desire of the user, with clear value
- Identified the Desired Qualities of the feature before discussing how it will work
- Avoided ALL tech rabbit-holing
- Squeezed a collaborative set of scenarios out of a room full of differently-minded people
- Achieved common expectations for the delivery.
Re-read the scenarios. You can FEEL it, can’t you? Let’s think about those Qualities we wanted - “Quick, works as you work, minimal waiting, clear disambiguation” - much more likely in the second Reality, wouldn’t you agree?
It just works.
Author: Mark Henwood | Mark’s LinkedIn