This is part four of the blog post series Large organisations find Lean UX hard, it’s not them, it’s us!, based on my talks at UXCambridge and UXScotland.
In this post we'll cover more tips, techniques and suggestions that will help you communicate more effectively with large organisations.
Educate and Empower
Do you remember what it was like to not know how to do something, to be a beginner? If not, try and remember the fear of first time you tried to ride a bike, or your first driving lesson!
Now try and imagine with the added pressure of ‘Seniority’ and all the engrained expectation of having all the answers, making the big decisions, of 'being the leader'.
We must educate and empower, gently and without undermining, with an understanding of all the fear and uncertainty our new colleagues will face.
Set expectations, clearly and honestly
We need to stop hiding the reality that our approach with software is to take small steps towards a solution, with regular check-ins with the business and customers to ensure we are building a solution that gives value to both.
We need to speak honestly, openly and positively about the possibility of failure, not just success. Wanting something to happen doesn't guarantee it will. There’s no point dancing around the realities. That being said there are ways we can help make that a positive conversation – however...
Fail Fast, Fail often! ... Umm, but ...
Fail Fast, Fail often! The rallying cry of start-ups wanting to experiment and learn fast. Experimentation is good...Faliure isn't.
When it comes to getting things off the ground, what others don't know can hurt you! Imagine hearing this as a stakeholder, with no explanation.
Unless you explain the value of failing fast and often, you're just proposing failing fast and often! Who'd want that?
"Call it fail small, instead of fail fast. If the culture is risk averse." Christiane Gerigk
Alternatively, I like 'Learn fast, learn often [, learn cheap!]'
Which leads me neatly to my next suggestion:
Reframe Language
I recently worked with a large company, who supplied me with some documents detailing the work they had already done. After looking at the document a few times, I had a nagging feeling that the phases were really closely aligned to Pirate metrics. Was this accidental? A coincidence? I asked the question, and it turned out that it absolutely was Pirate metrics, but by other names.
The reason? The exercise had originally been run with Pirate metrics phase names, but the people involved didn't respond well, so, the language was changed to better fit the business' tone of voice and re-run. The result was altogether different.
We work in an industry with many memes, acronyms, and domain specific terminologies. It's intimidating and also makes it harder for those unfamiliar with the language to contribute.
Do we need to use these terms? Do they add real value to our conversations?
| Industry Term(s) | Less intimidating Langauge |
|---|---|
| Customer Development / User Research | Talking to people to find out what they want or do. |
| Sprint / Iteration | Our working cycle |
| Stand-ups | Quick morning catch-up meeting |
| Journey Map, Story map, Impact Map, Wardley Map, Cynefin, A3, Business Model Canvas, Lean Canvas, design thinging, gamestorming | Tools and techniques to help us understand and discuss |
| Mockup, wireframe, paper prototype | Quick, cheap ways to test ideas without commiting to the cost of writing a full application |
| Hypotheses, Assumptions | Thinking about the problem we're trying to solve |
| Experiments, Metrics | Learning and measuring |
I'm not suggesting we don't use terms as a shorthand, once we know everyone feels comfortable with the underlying concept. I am suggesting we need to conciously not exlude or alienate people by assuming they understand and are comfortable using our terminology.
Glossaries
Glossaries can be useful as an initial introduction to a world of terms and concepts. It's a subtle way of mitigating people's fear of 'not knowing', as you can quietly look it up!
Glossaries can also be really useful on projects that have specific 'domain language' or language that can be use ambiguously.
You just said don't use jargon...What's a specific domain language? A real life example might help...
What do you call the thing you put in a light socket? I call them light-bulbs or bulbs, however my father in law, an electrical engineer finds this infuriating as in his (professional world) they are called lamps. Who's right? Both of us, but if I'm buiding a system for electrical engineers, I'd want to use the industry term.
Reframing tools and approaches
It can be hard to convey the value of a tool or an approach. It's often literally not them, it's us at this point - our assumptions of acceptance, and understanding have meant we've shortcut the explanation process.
So how do we make this clearer, without being patronising?
Demonstrate The Value / Show Don't Tell
It’s much easier to grasp a concept, or appreciate an issue if you see it, as opposed to being told about it. If you find something is not immediately clear, guide people gently through the method, this gets them comfortable with the approach and simultaneously demonstrates the value of the approach.
Try something different.
Our techniques are tools for getting a job done, they're not sacrosanct. If they're not working, as long as you understand what you want to get out, there are usually different ways to get at the same information.
Think outside the box (and act outside it). Try new approaches, if there isn't an approach that works, invent one!
Reframing Personas - Jobs to be done
I used to use pragmatic/proto personas - a lot - as a way of focusing discussions on user needs – I still do sometimes. However, we were recently running a workshop and personas weren't getting us where we needed to be.
It wasn't clicking with our clients, and we were getting blank looks - they were too polite to say, "what's the point of this?", but I'd hazard a guess that's what they were thinking.
Maybe this was due to the diverse nature of the groups we were considering, who couldn't easily be considered as a 'type' or the diversity of how the product might be used, depending on individual needs or possibly because none of the team had any previous experience working on a software product.
We wanted the same outcome - to understand why people would want to use the product, and what they'd want it to do. So we acknowledged the activity wasn't working and proposed trying something different.
We started discussing the product in terms of Jobs to be done . What job(s) do our users hire this product to do for them? This proved a much better approach, our customers got it, and it allowed us to consider the underlying emotional motivations customers were hiring the product for as well as the more obvious product 'features'.
Derisk The Process
We’re asking large organisations and the people in those organisations to embrace fear. We need to derisk that to make it palatable!
A colleague, kindly proof reading this, asked 'Can you derisk fear?' - It's a fair question – I think you can...or at least, I think you can make the fear / risk tolerable. An example of this. I don't like rollercoasters, but I'm way more likely to consider a rollercoaster with safety harnesses than one without.
Make your experiments Cheap!
We're looking for signals – initially probably weak signals. We should remember we're lean...and look for hacks that give us signals with as little cost as possible. (I consider time or effort to be a cost, as much as actual 'cash')
When we find a signal worth pursuing then we'll see if we can recreate and amplify it, with a more focused, experiment. This may warrant increasing your cost investment, but we should always be aiming for the least incurred cost possible.
It's vital, particularly in large organisations, to be lean with your experiment costs, otherwise the sunk cost fallacy can easily trap you into continuing to build something you know is wrong, simply because it's cost too much to cancel.
Play Out Scenarios
The ultimate cheap and safe to fail experiment – Act as if the decision is made.
It's that simple. If you're unsure what would happen if you made a certain decision, start acting as though you have. It'll help you think through the consequences, see what actions you might need to take, how people might react, and with no more 'cost' than the effort of pretending.
Next
In the final post in this series (coming next week) we'll look at how we might more effectively navigate the politics of large organisations.