Better Outcomes

The accidental age of moated silos

Sat, 16 May 2026 00:00:00 GMT

Everyone knows silos are bad. We're supposed to break them down. Work together towards an outcome. Be more collaborative. All solid advice. We should do this.

But with AI hype in full effect, everyone is afraid. Afraid for their jobs. Afraid for the devaluing of their discipline. Afraid for the loss of quality, competence and craft.

The "UX is dead", "Product is dead", "Coding is dead" posts are everywhere. Overwhelm and disillusionment are hard to avoid.

A common response is to go all in on AI.

Well, if you can't beat them ... The trouble is, this can end up with you accidentally digging a moat around your silo!

"We have integrated X domain specific tool(s) with Y MCP server(s) to achieve Z outcome. "

In theory that sounds great. And the robots love us! The trouble is most people in the business have no access to your tool(s) or the MCP server(s).

They care about getting the outcome they need with as little friction as possible. They also want to contribute. They have valuable insights, feedback, input. By 'tool-ifying' the solution, we've made our deliverables easier, but business collaboration harder.

Ironically, deliverables are the easiest thing to create. Hence AI can do them, in what looks like a faster way. They are also the hardest thing to make useful and correct. They're even harder to keep relevant. It's the discovery, definition, design and delivery that make them fit for purpose. And the ongoing alignment with needs that keep them relevant. This is still a 'people' game.

To humans our 'tool-ified' process makes us less open, easy to work with, less part of the solution.

So, what to do instead of digging a moat around our silo?

How about we tear down the silo and put up a big, open tent? With a reception area to guide people, a community space to grow together, and a clear and open set of guides on:

How to use the tools/services.
Access methods which are accessible with minimal knowledge.
How to contribute.
A roadmap. What we're working on and what's planned next.

Open source communities have been doing this for years. It's not new, it's well understood. The patterns are there. We should learn from them.

Thoughts on AI Tools today

Thu, 05 Feb 2026 00:00:00 GMT

Recently, I've been lucky enough to have the resources and encouragement to try some new AI tools.

I'm a professional cynic. (But my heart's not in it!)

Anyone who knows me, knows I'm excited by the possibilities of positive change from tech. I'm also a realist. (A cynical optimist?!)

Over the years, the people I've worked and with the communities I've been part of have shaped me. I care about 'craft' in all it's forms. I care about building the right thing and building it right. I care about code quality, testability and readability. I care about usability, I care about appropriate solutions to solve real problems.

So how does this align with the tools I've been testing?

Code

Claude Code is ahead for me on quality. I've found you can (usually) constrain the tool to follow your process. This will no-doubt continue to improve.

It will surprise no-one, that I'm as prone to the temptation to let them run away with themselves as anyone else! It feels so 'productive', like magic, It often isn't!

(I've also tried and continue to play with Gemini-cli and Mistral-vibe both of which do a good job, but I prefer Claude.)

Design

Design wise, Antigravity did a good job for prototyping and in fact code, (once I got it to play nice.). AI prototyping still feels like attractive elements rather than well conceived interfaces.

It depend what you need from your prototype I suppose.

I often find them akin to Photoshop mock-ups in back in the day. More of a sales tool than something you can get real feedback from as they tend towards superficial.

To be fair, it also depends who's 'driving' the tool and what the aim of the prototype is. My observation is that some of these "prototypes" are more of a no-code(ish) spike. These can be super-helpful.

The scenario that bothers me more is 'interface' prototypes which look too complete. I worry that it stifles feedback. I notice that the interfaces are often a composite of elements, that supeficially look correct. On closer inspection, whilst it "technically" achieves the needs, it's not a coherent whole. It's not easy or clear to use. (A jumble of non-obvious tabs being a common example.)

So, are they valuable?

Yes, they're valuable, and will no-doubt become more so.

In both cases though, the takeaway for me is that they are still tools. They can augment out abilities and enhance our capabilities.

What we need to do (imho) is stop treating them as sentient or godlike, and rather learn to use them better. To undertand thier edges, their leanings - each model has it's strengths and weaknesses.

With great power, comes great responsibility. The ability to put more crap in the world, faster, isn't in-itself valuable. You need a purpose, some sense of what success looks like and a set of standards. Otherwise, you're likely to create a disjointed mess, fast.

Why I'll never be a 'thought-leader'.

Sat, 20 Jul 2024 00:00:00 GMT

OK. Let's get right into it.

Why? Well ...

In most situations, there isn't a silver bullet solution.

I'm not a magician. There is no magic F13 key on my keyboard, I can't pull the answer out of a hat.

It's doing the hard work of understanding the problem, as a team, that makes for better solutions.

I don't want to preach one-true-path.

I'm not deriding those who do. They do a great job spreading ideas and starting conversations. 'Certainty' is very buyable. It allows change to happen in organisations that crave certainty. In one way, that's valuable.

It's hard to avoid if you're trying to be focused and succinct. It also helps you build a 'brand' around the framework, method etc. So I get it.

I'm just not comfortable suggesting "one size fits all" - it flies in the face of personal experience.

I don't enjoy public speaking anymore and find crowds hard.

I've done a lot of talks over the years, but since a later in life ASD diagnosis, I've recognised how stressful I find them. Due to this, I tend to avoid submitting conference talks nowadays.

I still love doing workshops though. They feel different.

They're figuring it out together - interactive and collaborative. Sharing, not telling.

I'm a terrible procrastinator when it comes to writing

So no book any time soon! 🤣

So what do I offer and how?

I work with teams to figure out the answers. I take time to listen, learn about a business, product, market, customers - absorb that, then:

I help teams figure out:

What they know – how certain they are, and why.
What they don't know – and how badly they need to know.
How we find out and how we test our learnings.

Bringing broad experience in research, design, agile, UX, product and strategy I help teams improve:

Design thinking, research and prototyping
Cross functional communication
Design, UX & SD
Lean and Agile practices
Business and product strategy

The Blacklist: As product people, what can we learn from Reddington's approach to life?

Mon, 27 Feb 2023 00:00:00 GMT

If you've (binge) watched The Blacklist, you've probably fallen a little in love with 'Red'. I know I have.

If not, why not? Check it out - I'll see you in 9 series time!

So, what can we learn from the Raymond Reddington approach to life? Minus of course the sociopathic criminality!

Know your primary goal and commit to meeting it.

What's yours? Are you and your team committed to it? If not, why not? Lack of alignment with the goal is why people quit.

Success is not a direct or easy path.

There will be casualties. In our case good ideas, products, features and business opportunities may not make it. Learn to live with that.

Hack/Use the system.

Some rules are stupid, bend them, break them or subvert them.

Most 'systems' are a collection of rules to stop a previous failure occurring again. This risk aversion can stop innovation. Seek forgiveness not permission and operate below the radar.

Build, curate and use informal networks.

Most organisations have an overt network. The real work gets done via the informal networks that are often hidden.

Knowledge is power.

Learn faster than your competition. Red looks at information from sources that others don't consider. Then he connects the dots in unconventional ways to gain insight others can't. What aren't you looking at?

Sometimes you have to get comfortable with Chaos.

Be flexible in the face of new information.

What's in it for me?

People respond better when there is a win in it for them. Figure out what wins people want and deliver them. You'll get much better buy-in.

Trust your team - "Value loyalty above all else."

But only to a point ... Autonomy with accountability. Can you trust your team to do what you agreed? Have you got a relationship that allows you to let them know when they're not? Can they tell you if you're not keeping your promises? When we take ownership of doing something, we also become accountable for it.

Situational Ethics

Decisions aren't black and white, they're murky grey. Situational awareness helps make better decisions based on the full context.

Distract with unexpected humour to de-pressure a situation

Sometimes the best way to calm a tense situation is to focusing attention elsewhere.

Red usually notices a detail and riffs on it. I'll leave you with an example.

Red (trying to get information from a gunsmith): "Is that a 416 rigby mauser? And fully loaded no less ... An african bull elephant weights 14,000lb. And this can bring one down. I happend on one of those magnificent creatures in the Zambezi valley and one of these came in quite handy?".

Liz: "You shot an elephant?"

Red: "Lord, no. I shot the poacher who was about to kill the elephant."

(PS. If you want more someone has done the work for us.)

I have writers block.

Wed, 04 Jan 2023 00:00:00 GMT

Like – 4 years writers block.

I have two loooong lists of ideas for blog posts. Can't start 'em. If I do start, I can't finish. I have a pile of abandoned, half-written blog posts.

They're not good enough. No will care...It's all so obvious why would anyone get any value out of this?

It appears I have developed some sort of imposter-syndrome when it comes to writing. (There's a blog post I can nerver write in the why.)

Anyway. I've realised over the years, that the best way to combat being afraid of something, is to get it out there, to see that the consequences aren't terrible.

So here I am. Writing again for 2023.

Not so much a new years resolution, as a statement of intent.

Better Outcomes - what does this really mean?

Mon, 10 Aug 2020 00:00:00 GMT

There's a lot of talk about focusing on 'outcomes'.

This mainly originates from LeanUX-land, and the mantra, 'Outcomes over Outputs', which as soundbites go, is mainly good advice, but it's also exactly the kind of catchy, short form, tweetable phrase that is memorable and repeatable, but on it's own, not that actionable.

So, better outcomes...

We'd all like better outcomes, but what does that mean? And what will it take to get us there?

I'm an generally a bit of an idealist, so I'd like to think that means to really succeed, they need to be better for everyone, (and society, and the planet, and the future).

Better:

Clarity on "Why".
Focus on customer needs
Discovery & Research
Collaboration
Communication (in every direction)
Meetings & workshops
Goal Definition and alignment
Planning
Progress tracking and reporting
Visibility across Dev, UX, PM, Org
Continuous learning & Iterative improvement
Autonomy based on trust with responsibility
Procedures and processes everywhere (More human, less bureaucratic)
Culture of inclusivity and contribution

If... we can achieve all of these we'll have happier customers, empowered teams, who are solving real problems for customers and creating actual value for their organisations.

Uhhh, that's quite a lot of things...

Maybe we can work through that list and it'll all be good?

Well, it's not really a list...it's more like this.

So, where do we start? Of course, in time honoured fashion, it depends.

It depends on where you are in your product/service/project lifecycle.
It depends on where your organisation is culturally.
It depends where your team(s) are at in both maturity, resilience, happiness and how much friction they can tolerate/thrive on.

Well that's not very helpful it is, what do I do now?

I am going to try and answer that in the next blog post "So, where to start?"

So how much is it going to cost? Agile Estimation and the Bathroom tap...

Thu, 02 Feb 2017 00:00:00 GMT

Originally posted at Cultivate

So, how much is it going to cost?

I don't know about you, but we get asked this question pretty regularly. And it seems like it should be a simple answer. Most applications are mainly made up of component parts that are solved problems, like a CMS, signup, a login system, authentication, email sending etc. The expectation is that you'll give a figure, a timeframe and then deliver on time and in budget, which when you say it like that sounds perfectly reasonable.

Why are you talking about bathrooms?

There's something about houses that always makes me think about software. The different layers of interactivity of things, the coupling of systems, the hidden plumbing, the lock-ins of previous choices and the value decisions around improving them.

Basically, We've recently moved house and need to get the bathroom refitted. Exciting times. Bear with me, there's a point to this I promise.

Knowns.

Estimating the cost of a bathroom. We know the size of the room, and there are things we can see we need – some components – a sink, a toilet, a shower, a bath, something to protect the walls from water, lighting, heating, flooring, paint. These are our knowns, that sounds like it should be easy...

However, because I'm not a DIYer or a craftsman I don't know what my options are, and even if I do, I probably can't express it in the right way for an expert.

"What radiator valves do you want?" "Umm. I like chrome ones?" "Yes, but what kind? Thermostatic? Wax or water? Upright or sidevalves? Branded or unbranded, oh and towel-rails are different to radiators, so which valves would you like us to estimate?"

This applies to pretty much every choice. So I have to:

Be confident enough to say, I don't understand and am not best placed to make some of the decisions, and hand over control (and by extension - risk) to an expert.
Rely on my expert's willingness to spend time helping me understand, and their expertise and their alignnment with my goals, and mental picture of what success looks like
Know which decisions I care enough about to not hand off to an expert.
Understand what 'good enough' means in any given context.
Know what I'm prepared to compromise on and what I'm not.

What could possibly go wrong?

Back to our software project.
"I need to manage my content"
"Do you want a CMS or a static site generator? Middleman, Radiant, Refinery, something not rails? Wordpress?"
"Umm...I don't know - I just need to manage a few pages to convince people to try my product"
"How many pages?"
"maybe 4?"

That's good – we're having a conversation, narrowing options, gaining shared understanding, maybe even agreeing scope, but this all takes patience, time, and effort which equate to cost (or billable time) and doesn't deliver the "Oh, yeah it's £20k and it'll be done in a month" that people want when they ask "How much will it cost".

If we and our clients are prepared to examine the details, our knowns are known and fairly accurately estimable.

Known unknowns

Back to the bathroom. We'd like to drop the shower back to floor level – it's currently raised a little - presumably to allow for plumbing, but we don't know that it's just for ease... It could be that the joists run in a direction that makes it impossible to drop. I know...a bit technical, sorry.

The point is, we can't know until we start ripping the existing bathroom apart. We'll need to lift the lino, remove the skirting, lift floorboards etc. This will all need doing anyway when we start, but we don't want destruction while we wait.

So, my options are:

Insist our fitter give me a fixed price.
Accept that we don't know and we'll have to figure it out when we do.
Rip things up now and find out.

If I insist on a fixed price, I'm essentially moving all the risk onto our fitter who now has limited options. As far as I know he doesn't own a crystal ball, so he can:

Persuade me I'm wrong!
Eat the risk/cost and hope for the best
Increase the quote to cover his risk, but potentially then look expensive
Refuse the job (as I'm a PITA).

Trust & Reputation.

What we're really talking about here is trust. I trust our fitter, I'm not going to ask him for a fixed price, I know that he'll recommend the best thing, and in recommending, will explain any trade-offs that I need to be aware of.

I also trust that he won't recommend unnecessary work, or choose expensive or time consuming options to extend the engagement. He has work queued up, he doesn't need to.

This trust is based on four important things:

Recommendation. We had a glowing recommendation from someone as fussy as I am so we immediately had an element of trust as a starting point.
A reasonably accurate estimate of what is estimable
Being clear around what currently isn't (i.e. where the risks are)
Having proven himself on the first job (and every one since).

Basically, I've learned over time that I can trust him to make certain decisions without needing my input and that he'll ask if it's something he knows I'll have a view on.

Don't under-estimate estimation

Don't under-estimate the amount of time and effort you'll have to invest to give good enough estimates especially on a 'maiden' project with a new client if you want to earn trust (and by extension, potentially repeat business and recommendations)

Unknown unknowns

I was wondering how I'd give an example of an 'unknown unknown' to finish this post - I needn't have worried.

An unknown-unknown

The bathroom is gutted, back to bare floorboards and pipes. Shower gone, bath gone, sink gone, tiles gone...you get the idea. The new items have all been ordered, paid for and delivered.

So we start to plan out the exact placement of the splashbacks. And that's when it happens...

'So we're going to put the sink here...'
(draws on wall with sharpie)

'Great, as we have it in the garage, can we place it there - just to see it?'
... basin is placed ...

'Ohhhh - TAP...you won't be able to open the window...we'd not considered the height of the tap... ****!'

To be clear, this was not our fitter's fault! No-one had spotted it and at least 4 people had looked at the plans. Maybe a 3D rendering of the plans would have picked it up - probably not.

So one small element triggered an on-the-spot, live redesign of the bathroom – Four people, an hour, lots of discussion, and sharpie marks on the walls combined with physically placing all the items and we had a solution. It's not the original design, but it contains all the elements we wanted, without compromising on things we felt were 'non-negotiable' so we're happy - it might even be a better design, it's certainly not worse.

Focusing on outcomes

This is the reason we encourage people to focus on outcomes not solutions. The outcome we wanted was a clean, functional well fitted bathroom, with the essential elements included, that maximised the space in the room.

I don't really care if the sink goes under the window. What I absolutely do want is the high-level outcome, if those criteria are still met, I'm happy.

Conversely, If we'd provided exact specifications, or even overly detailed 'feature requests' to someone who 'just does what they're told', we could well have ended up with a situation where existing plans were followed blindly, and we only learned about the tap when we came to open the window and found it didn't open.

What are the takeaways?

Estimation is hard, there will almost certainly be unknown unknowns that will bite you...Try and make clients aware of this as early as possible.

It's not just software that's hard to estimate, sometimes looking at another craft helps us find less 'techie' ways of communicating why these things are hard.

Earn and retain trust:

Be recommended (You can't control this, but if you're not, expect to work longer and harder to earn trust)
Estimate that which can be estimated as accurately as is reasonably possible and be clear
Be clear where estimates are uncertain or impossible (i.e. communicate where the risks are.)
Prove yourself, over and over and over again.

Large organisations find Lean UX hard, it’s not them, it’s us! - Part Five: Navigate The Politics.

Mon, 31 Oct 2016 00:00:00 GMT

Originally posted at Cultivate

This is the final blog post in the series Large organisations find Lean UX hard, it’s not them, it’s us!, based on my talks at UXCambridge and UXScotland. This post will look at how we might navigate the politics of large organisations more effectively.

Acknowledge The Pressures

There are many types of pressure on organisations and people (internal and external).

My first tip - remain demonstrably focused on understanding the expectations on scope, platform, delivery, budget etc. Make sure people know you're taking their needs into account. Capture these needs on whiteboards, or flip charts - something big.

Organisation Health Metrics

I came across the idea of Organisational Health Metrics in Christia Wodtke's book Radical Focus and I think this is something we can use to reassure the business that we understand the issues they face.

As I understand them in OKR terms 'health metrics' are things you want to protect as you try to improve whatever you're focusing on. These can be as literal as health of your staff, or something less tangible, like brand values. For example, if you make environmentally friendly shoes, it's not acceptable to improve productivity by using toxic tanning agents.

Recognise your own assumptions and expectations

We should not assume that our expectations are in line with the stakeholders/execs/finance/business...We want to work 'time and materials' as we're agile...finance hear 'RISK: Open-ended contract with no agreed deliverables or deadlines.'

It's often not us who pitch these uncoventional approaches to the organisation either, so we're asking people to risk something very dear to them on our behalf.

Personal Reputation

Personal reputation is extremely important to most people. It's often what our self-image is build around, and how in part we measure achievements. I believe this is amplified by our use of social media, especially in the young. "How many likes did I get? How many followers do I have?"

Large organisations are usually extremely hierarchical in structure. Reputation influnces opportunities, duties, promotions and potential salary. That's what we're asking people to stake on us.

We need to try and help them feel less reputationally 'at risk' when we ask that of them.

Ask What would you be comfortable changing?"

Ask what would you be comfortable changing and work back from there, you might be able to move the boundaries a little, but you'll almost certainly need to prove you can deliver before you'll be able to move them dramatically.

Earn Trust - Be honest, be humble, over-deliver!

We're sometimes (often?) asked to do things that are outside of our remit. If you have the time and skills, do them!

One example of this that sticks in my mind, is when I was asked to design Powerpoint slides for a client. I had the capacity at the time and so pitched in.

This meant that the person I was working with had a presentation they were more comfortable giving and that helped get buy in for our project. It took a couple of hours, but the value all around was far greater than that. I'd earned trust and demonstrated how 'cross-functional teams' operate.

If opportunities don't present themselves, just help clearing up after a meeting, or workshop or lunch.

Admit you don't know.

None of us know everything. Let's start saying so. When we admit we don't know, it makes it safer for others to say they don't know either. Over time this allows conversations to be had around what we need to learn, not what we 'know'.

Ask “Why?” (and then listen to the answer)

It sounds so obvious, but we often don't listen to the answers to questions we ask. Or we think we do as we half-listen, preparing our response in our head.

“We can’t do that” Why?
“Those systems can’t be changed” Why?
“We can’t pay users for their time” Why?

Sometimes the answer will really be a reason you can't do something and that's useful to know. Sometimes it will reveal there is scope to work around the situation. (OK, what if we did XYZ?) If you're really lucky asking why will reveal the reason isn't really a blocker, and we can ignore it, but you'll often miss these cues unless you are listening fully. I also find reflective listening useful to confirm what I think I've heard is in line with what's actually been said. (Warning - overuse can be counter productive!)

Visualise Things (Draw)

Draw. Maps, comics, diagrams and visual/sketchnotes.

You’ll be amazed what this opens up communication wise. People notice, then they ask about it, then they want to show someone, soon it’s being used to frame a problem and you’re asked to do more...earning buy-in and trust.

Teach people to draw - well enough.

Drawing isn't hard, but people think it is. Let's derisk it for them.

More often than not, people believe that nothing less than a 'Leonardo Da Vinci' level of ability is good enough. We're not creating fine art, we're discussing ideas. Almost anything is better than nothing, a scribbly napkin sketch prompts conversation, and that's what we need.

There are lots of great resources out there to get people started. I was lucky enough to attend Bonny Colville-Hyde's How to Make Your First UX Comic or Storyboard. I learned lots of great new (simple) techniques. She has a page with lots of slide decks and resources here

Use the informal networks.

One of the biggest challenges when you start working with a new organisation is to get a feel for the politics and the people. I usually - depending on the engagement, try and spend a couple of days orienting myself by speaking to anyone and everyone involved in the project. This is usually a casual chat. Often, during this 'walking the business' time, I'll need to speak with someone, not directly on the team, so I'll ask people, who should I speak to in department X. Often they don't know, sometimes haven't even heard of department X. If you're lucky they'll say, I don't know, but you should speak to Jane she know's everyone. Find your Jane, befriend them (not in a cynical way!). They will help you navigate the “undernet”

Mitigate The Hippos

How often have you heard "I know what users want", followed by a personal opinion. It could be right, but it could also very well be wrong, how do we manage that?

Whilst arguing the point early on may be worthwhile sometimes, I've found objective proof to be the most powerful way of changing people's opinions.

Sometimes, building a prototype then user testing is our best solution. I find video of person after person struggling to use something, is far less disputable than one person's opinion versus another (despite how much experience you may have!)

Find New Ways / Hack The System / **** the Status Quo

We're in an evolving industry, there are few if any 'right' answers, just tools and techniques we can try. Sometimes there is no solution that fits your needs – necessity is the mother of invention, figure it out, and share back your learnings with the broader business, and the community where possible.

You Too Must Compromise

I'll leave you with this (paraphrased) though:

Grant me the serenity to accept the things I cannot change,
the courage to change the things I can and the wisdom to know the difference.

Reinhold Niebuhr

Large organisations find Lean UX hard, it’s not them, it’s us! - Part Four: Speak Simply, Teach Gently And Derisk The Process

Wed, 19 Oct 2016 00:00:00 GMT

Originally posted at Cultivate

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.

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.

Large organisations find Lean UX hard, it’s not them, it’s us! Part Three - Extend Your Remit

Wed, 12 Oct 2016 00:00:00 GMT

Originally posted at Cultivate

In the previous post in this series, we covered why you need to focus on oucomes. In this post we'll look at a couple of techniques I like to use to elevate the conversation to a more strategic level.

Extend Your Remit

I believe we need to extend our remit beyond ‘Lean UX’ to encompass strategy to help our organisations into a position of being able to consider outcomes.

I have two favourites 'tools' for this Wardley Mapping and Impact Mapping.

Wardley (Value Chain) Mapping

Something I've found extemely helpful talking to senior leaders is what Simon Wardley describes as 'Situational Awareness' and the manifestation of this as Wardley Value Chain Maps.

I'd suggest you read everything on his blog – if you're like me, you'll probably read it more than once as there's a lot to absorb.

You may not want to do that right now, so an extremely high level (and probably inadequate) description of the idea is this:

Start with user needs
Create a value chain
Map this on the vertical axis from invisible to visible
Map your components along the horizontal axis as evolution with a scale of:
Genesis > Custom Built > Product(+ Rental) > Commodity (+Utility)

This shows you where you are. From this you observe the map, look for where you can gain strategic advantage. This might be done by moving a component forward through it's evolution, aggregating existing technologies to reduce waste, consuming other's technologies, or a myriad of other possible solutions.

You can then use this for planning your actual work, from what technology choices you might want, to what process best suits managing where a component is in it's evolution.

Beyond the planning however, comes the real value, by visualising where you are in this fashion, you can spot new routes to disrupt your industry, potentially surpassing your competitors, by concieving of a future they hadn't.

Impact Mapping

Impact mapping is an idea and book from Gojko Adzic.

The below explanation is lifted from here. I've restructed it slightly to explain the value before the process.

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people.

Project plans and requirements documents are often shopping lists of features, without any context why such things are important. Without a clear mapping of deliverables to business objectives, and a justification of that mapping through impacts that need to be supported, it is incredibly difficult to argue why certain items should or shouldn’t be invested in. In larger organisations with many project stakeholders or product sponsors, this leads to huge scope-creep as everyone’s pet features and ideas are bundled in.

An impact map puts all the deliverables in the context of the impacts that they are supposed to support. This allows us to compare deliverables and avoid over-investing in less important areas of a system. It also helps to throw out deliverables that do not really contribute to any impact that is critical for a particular goal. Finally, by connecting deliverables to impacts and goals, an impact map shows the chain of reasoning that led to a feature suggestion. This allows us to scrutinise those decisions better and re-evaluate them as new information becomes available through delivery.

An impact map is a mind-map grown during a discussion facilitated by considering the following four aspects:

Goal

The centre of an impact map answers the most important question: Why are we doing this? This is the goal we are trying to achieve.

Actors

The first branch of an impact map provides answers to the following questions: Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it? These are the actors who can influence the outcome.

Impacts

The second branch level of an impact map sets the actors in the perspective of our business goal. It answers the following questions: How should our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are the impacts that we’re trying to create.

Deliverables

Once we have the first three questions answered, we can talk about scope. The third branch level of an impact map answers the following question: What can we do, as an organisation or a delivery team, to support the required impacts? These are the deliverables, software features and organisational activities.

Learn about impact mapping

Further Interesting Ideas

Outomes, goals, capabilities, activities – so many words so many ways to think about things. I find reading as many views around an idea as possible helps me triangualate what I think makes most sense / works best, but also give me alternative approaches should something not be working with a particular group. From a pure 'outcomes' point of view, I find both of these ideas a bit 'in the weeds' and would prefer to operate at a higher (more 'destination') level.

However they both become really useful once you have your higher level outcomes clearly defined. Then you need to get into the weeds!

Here are a few articles I've enjoyed around this topic.

Liz Keogh's Capability based planning which is a follow up to Estimating Complexity in which she discusses her risk scale.

Just about everyone in the world has done this.
Lots of people have done this, including someone on our team.
Someone in our company has done this, or we have access to expertise.
Someone in the world did this, but not in our organization (and probably at a competitor).
Nobody in the world has ever done this before.

Jeff Patton's work on story mapping is well worth reading around (He talks about 'abilities' which seem similar to capabilities in Liz's terms).

It's no coincidence that most of the things on this page are ways of mapping. For me, visually representing information makes it less confusing and intimidating, and more coherent. Of course beyond helping us better understand the situation as individuals, the real power is that you can see it as a group.

Next: Speak Simply, Teach Gently And Derisk The Process

Large organisations find Lean UX hard, it’s not them, it’s us! - Part Two: Outcomes!

Thu, 29 Sep 2016 00:00:00 GMT

Originally posted at Cultivate

In the previous blog post we looked at the reasons large organisations are struggling to implement Lean UX successfully.

In this post, I'd like to share my number one approach to improve our situation today.

Outcomes

If you don't read any further and only take one thing away let it be this: Focus on outcomes, first.

Pretty much every project I've seen fail has started off with poorly expressed outcomes or no defined outcomes at all.

A project without a clear goal is like a rudderless boat...It'll go somewhere, but that'll be wherever the wind and the tides take you.

Without clear, coherent, achieveable goals, we don't know what success looks like, so delivering it is virtually impossible.

Outcomes set destination for the project.

This is key for me. Outcomes set the destination for the project.

A destination (outcome) is not a route.

The most performant teams I've worked in or with understand the desired destination and are emopowered to figure out the best route to get there.

Understanding the desired outcome (destination) allows us to head towards that and measure if we're getting nearer.

A route is flexible.

The route will almost certainly have to change as we learn of obstacles we couldn't predict. Similarly, our measurements will change as we learn more about our route.

Outcomes need to be measurable

An outcome needs a clear and measurable definition of success. There are many ways to shape this, and I'd suggest you try the one that you think will chime most strongly with your organisation.

What we need to know is:

What are the businesses goals? Are they measurable?

SMART Goals

This is a favourite of mine, as it really helps walk through the things that need to be clarified and agreed. If an outcome can't be expressed to meet these criteria it's ususally not actionable and needs revisiting.

I tend to use these definitions for the acronym.

Specific
Measurable
Attainable/Achievable
Relevant
Timely

However these are muddy waters and so I suggest you state which definitions you are using - ideally on a slide or handout whilst you're undertaking the activity.

OKRs

I recently read Radical Focus by Christia Wodtke. It's a light, entertaining read, with a great narrative. In it she explains the idea of OKRs. OKRs seem to me to build on the idea of smart goals, merging them with agile 'checkins' and 'celebrations' to introduce a shorter, focused cadence.

So what are OKRs?

OKRs are an Objective[O] with measureable Key Results[KR]. These are best expressed at a company level, to drive a cohesive direction, but could also be expressed more specifically at a departmental level. They are usually based on a 3 month period.

Each week, you have a check-in at the beginning of the week and a celebration at the end. (example below)

To keep our information visible, a simple format is used - and it's a quadrant!

The top right quadrant

Contains our objective, the key results associated with it and our confidence of achieving them within a 3 month period.

In the example below our objective is 'To become known as a go-to source [Top 3] for Lean UX consultancy and workshops in the UK'

We'll measure our success against the three Key Results, which are initially marked 5/10 each. the 5 out of 10 indicates likelyhood of succeeding and should always start as 50.50, otherwise you're not pushing yourself enough. (You should set your Key Results to be stretch goals.)

The top left quadrant

Contains this week's ordered priority activities.

The bottom right quadrant

This is Organisational Health. I love this idea. It's a little confusing in our example, as I wasn't to book anyomre speaking engagements (I was overloaded). Please don't misinterpret this as personal health (which is obviously important!), whilst this seemingly involved personal health, it was more around business capacity.

A more clearly business related example might be "We cannot increase productivity in ways that undermine our core values. (e.g. No sweatshops)" or "We must keep our existing customers happy as we grow our customer aquisition"

The bottom left quadrant

Here we surface relevant things that are on the horizon (next four weeks). These can be anything that's relevant and shouldn't be forgotten e.g. events, upcoming work or things that will need doing.

From my reading of the book, I feel this approach may be more ease to embed at a company with a start-up mentality, but I feel it'd be particularly valuable in large organisations. Given this from wikipedia:

"OKRs were invented at Intel. OKRs are used today by many companies, including Uber, Google, LinkedIn, Twitter and Zynga."

...it should be doable. That being said most of these companies are 'startup-ish' in mentality and I've not yet personally tried to introduce OKRs to a large organisation, so we'll see!

You can watch Christia Wodtke explain ORKs here:

Push back if they're not defined.

I believe it's our job to help guide our organisations to success, and I genuinely belive outcome are the genesis of success, if you find they're not defined, or unclear - push back! Politely question the outcomes, organise a workshop, do what you need to do to get them clarified. Everyone will benefit in the long run.

Life is change - Revisit your outcomes

Life, business, the world - everything really aren't static – they're constantly changing. I'd suggest revisting your outcomes quarterly to review if they are still current. In lean terms should we 'Persevere, Pivot or Kill'?

Maybe by now you're thinking, "that's all well and good, but I can't get our leaders to think about outcomes." in the next post in this series we'll look at how you can Extend your remit.

Large organisations find Lean UX hard, it’s not them, it’s us!

Mon, 19 Sep 2016 00:00:00 GMT

Originally posted at Cultivate

Many large organisations say they want to use a Lean UX approach. In my experience, they don’t find it easy to execute in reality.

Why is this? I believe we’re not helping adoption happen – we’re not following our own advice or approach, I say we can do better.

I talked about this at UXScotland and again at UXCambridge. I promised to write the talk up as a blog post. I've decided to split this over a number of blog posts, this is the first of that series.

This blog post will cover why we're not getting large organisations adopting Lean UX the next will look at what we can do to help.

So why is Lean UX so hard for large organisations?

I’d like to start with a short story.

Your competitors appear to be innovating.

They’re talking at conferences about how successful and lean they are, how they’re innovating and iterating on new customer centric products.

The executives get scared.

What’s everyone else doing?

“Digital Transformation”, and a “Digital First Strategy”? Why aren’t we doing that?

No one points out the elephant in the room

“What is an innovative digital first strategy - what does that mean for our business?”

If you’re lucky, someone did point out the elephant, and there are some outcomes or goals defined!

The executives initiate a ‘Digital Transformation’ with a ‘Digital First Strategy’ powered by ‘innovation teams.’ Go forth and innovate…

Then – nothing happens, people are trying to start, but your business have limited or no in-house capability. The executives are informed - and take decisive action.

Consultants are hired. In Droves.

From different companies with different approaches! (And with no clear direction.)

An agile approach is adopted by the dev team.

Standups are 30 minutes long and some people are not allowed to talk as they are chickens (No one explains what a chicken is (or that it’s an outdated concept) - just that these high-level execs are chickens, and therefore can’t speak.)

No-one is entirely sure if Digital Transformation trumps existing KPIs / initiatives etc. but carry on doing anyway.

Consultants attempt to engage with and educate the executives using lots of domain specific terminology.

Innovation, resonate, customer development, minimum viable product, sprint, story points, iteration, burn down, burn up, assumptions, hypothesis, experiment, kanban, swim-lanes, six-sigma, lean, cynefin, real options.

The execs are excited. They talk about experiments, customer centricity, learning, being lean and agile… It’s a top down directive. Yay! Go forth and be lean…

Books are bought - Lean UX, Sprint, The Lean Enterprise

Maybe they're even read, possibly superficially understood

We’re ready, we’ve got mapped our assumptions, captured our hypothesis, we’ve co-designed our MVP.

You are 100% encouraged and ‘empowered’ to be both Lean and Agile.

But wait...there's some small print!

"Within the constraints of a quarterly profit reporting cycle, and working with IT’s six month lead time, assuming you have budget in place a year in advance."

Oh and, there are a few ‘rules’

We’re not a startup, we can’t do all that startup stuff, so:

You’re not allowed to talk to customers.
- They’re too important/busy/have been over communicated with.
- You can’t pay customers for their time, even though our customers are professionals
We have a brand, we can’t devalue it with incomplete things
Don’t cannibalise the existing business
Don’t come to us with ideas that don’t fit the existing strategy

Sound Familiar?

The Lean UX 'Principles'

So, with this familiar story in mind, let's look at the Lean UX Principles and the issues I've seen in implementing them.

<table> <thead> <tr> <th> Principle </th> <th> Issue(s) </th> </tr> </thead> <tbody> <tr> <td> Cross Functional Teams </td> <td> <ul> <li>Education</li> <li>Capability</li> <li>Silos</li> <li>Reporting structure</li> <li>Departmental KPIs</li> </ul> </td> </tr> <tr> <td> Small, Dedicated, Co-Located </td> <td> <ul> <li>Small. Hard in a large organisation</li> <li>Dedicated. Often not (this can be changed)</li> <li>Co-Located. Geography and makes this hard</li> </ul> </td> </tr> <tr> <td> Progress is outcomes not output </td> <td> Only if outcomes are understood and acceptable </td> </tr> <tr> <td> Get out of the deliverables business </td> <td> <ul> <li>Very hard for a traditional business to understand</li> <li>Very hard for them to execute on</li> </ul> What have you been doing? “Learning”... Where’s my product? </td> </tr> <tr> <td> Rapid Prototyping </td> <td> Reputational worry </td> </tr> <tr> <td> Problem Focused Teams </td> <td> Teams may be problem focused, but organisational silos often still have conflicting KPIs/desires/requirements </td> </tr> <tr> <td> Removing Waste </td> <td> Risk to people’s: <ul> <li>position</li> <li>security</li> <li>comfort</li> </ul> </td> </tr> <tr> <td> Defer Decisions </td> <td> Whilst not a Lean UX principle, defering decisions is an important part of an agile approach. However most large organisations have extremely long budget and planning lead times. </td> </tr> <tr> <td> Small Batch Sizes </td> <td> Everyone wants to see the entire concept and wants their idea included so a small design inventory is very hard to achieve. </td> </tr> <tr> <td> Continuous Discovery / Get Out of the Building </td> <td> <ul> <li>We did user research 2 years ago</li> <li>We can’t show users … Our product is secret</li> <li>Users are too important / busy</li> <li>I KNOW what the users want, just build what’s in my head</li> </ul> </td> </tr> <tr> <td> No: Rockstars, Gurus and Ninjas </td> <td> Often you can’t pick your team, they are assigned and changed in and out. Worse still people are promoted to a role without the skills or experience to deliver. </td> </tr> <tr> <td> Shared Understanding & Externalise your work </td> <td> <ul> <li>How can you share this across a large disparate group?</li> <li>To where? To Whom? How?</li> </ul> </td> </tr> <tr> <td> Making Over Analysis & Learning Over Growth </td> <td> We like making. You are making the finished product now though, right? </td> </tr> <tr> <td> Permission to Fail </td> <td> Failure sounds bad. Therefore, there is no failing, only massaging of truth into success. </td> </tr> </tbody> </table>

OK, enough of the problems, how can we fix it?

In the next blog post(s), I'll talk about some of the things I think we can do to help get things working.

Seven techniques product leaders can use today to get a project focused

Thu, 23 Jul 2015 00:00:00 GMT

Originally posted at Cultivate

Are you frustrated by a culture that hasn't caught up with the digital world?

Do you feel like you're building the wrong thing? New features fail to engage and delight customers?

Are you fighting against a culture of inertia? Trying to sell processes to people who don't understand the business value? Are you in a project that's become too big to fail?

This blog post is a few tried and tested techniques, I've found useful to help get projects on track and everyone on the same page.

1. Understand the 'Why'.

Nothing exists in a vacuum. It's vital we understand the goal. Products need a purpose, both at a project and functionality level. What are you trying to achieve and what business value it will bring? This may not be a quantitative value, it could be as fluffy as more customer happiness.

Innovation games are a great way to get at the why, and work well in workshops with a broad spread of stakeholders. These games often surface misunderstandings, leading to discussion and consensus.

Here are a few examples I've games found valuable in this context:

Pragmatic Personas

Pragmatic Personas are a quick, easy way for you and your team to think about who your users might be and what they might want or need from your product. They're non-research backed and draw on the knowledge in your team to get you started quickly. This makes them ideal for identifying who you might want to talk to in you customer development phase. During your customer development or user research activities, you can compare your assumed personas against really behavior and then revise your personas to better reflect your learnings.

The Elevator Pitch

Using the below format, working in pairs, define the elevator pitch for your product.

<pre> For: (User Type) Who: (Need to be fullfilled, or job to be done) The: (Name of your product) Is a: (Description of the product) That: (USP of product) Unlike: (Competitors or existing product) Our Product: (Improvement over current state) </pre>

Design The Product Box

What differentiates your product? People buy benefits, not features. Imagine your product was competing for attention on a shelf full of similar products, design a box to get users to buy your product over the others.

2. Focus on outcomes not features.

We work at an amazing time, in an industry full of smart people who want to do great work. Technology has come far enough that we can create incredible solutions to complex problems.

We don't need to have the answers any more, we need to know how to ask the questions. If you can ask for an outcome not a feature, you'll have a happier team, and a better product.

Gojko Adzic's Impact Mapping technique is a favourite of mine for getting stakeholders talking about outcomes not features.

The idea is to start with Why (as discussed above, you can use the assets generated to feed into this activity as reference)

Why?

This is the goal and ideally should be expressed as a SMART goal (Specific, Measurable, Action-oriented, Realistic and Timely)

Goals should present the problem to be solved, not the solution. This is doubly valuable when working with non-technical stakeholders, as it levels the field and de-risks contribution.

Who?

This part of your impact map is about actors. Try to be specific, avoid terms like 'users'. The more specific you can be the better, so if you can list specific users, great. If not, decrease the granularity through personas to role/job title or finally group/department.

Not all 'actors' are equally relevant. To prioritise, you want to consider how central they are to the project. Alistair Cockburn advises looking for three types of actors:

Primary actors, whose goals are fulfilled, for example players of a gaming system
Secondary actors, who provide services, for example the fraud prevention team
Off-stage actors, who have an interest in the behaviours, but are not directly benefiting or providing a service, for example regulators or senior decision-makers

How?

Here we're looking for Jobs to be done, not solutions to the problem. It's also good to try to show how the job is improved – e.g. 'Print twice as many t-shirts per hour' rather than 'Print more t-shirts'

What?

What can we do, as a team, to support the required impacts?

This is where your 'scope' is, options, features you could build, or activities you could undertake to move you towards your goal. Try to keep out of detail here, early on as this the area that contains the most assumptions. Pick a route (the shortest, or most likely to succeed) and run a lean test. If it succeeds, great, carry on. If it fails you can have options! Revisit the map and try the next most likely path.

3. Make your metrics actionable.

Great metrics should be actionable and drive changes. The question you should be asking is 'What will you do differently based on your results?'

One of my takeaways from the Lean Analytics book was 'One Metric That Matters'. This doesn't mean you won't track anything else, but it does mean you know what the one metric really driving your business is.

The book breaks down metrics based on what phase your business is in (Empathy, Stickiness, Virality, Revenue and Scale), and also by what kind of business you're in, to help you figure out what metric might be appropriate.

If you haven't read it already, it's a great book. You should read it.

4. Don't forget the past (Check-in regularly).

Those who cannot remember the past are condemned to repeat it - George Santayana

It's easy to create lots of learning, capture it, file it somewhere and forget about it. Not deliberately, not maliciously, not lazily – just we're busy doing, time moves on and we forget we have these items we can refer back to when we tell our stories.

Keep referring back to your learnings. Some assets we might check back in with:

Inception Learnings
Project Pre-mortem
Storymap
Customer Development notes
Vision statements
Your customers

Another great way to remind yourself to check-in is to create an area that all these documents can remain visible, public, discoverable and importantly, questionable.

5. Defer Decisions.

In Estimation is Evil Ron Jeffries says - at the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we 'require.' This really resonated with me, especially in combination with the Real Options thinking of Chris Matts.

Options have value
Options Expire
Never commit early unless you know why

6. Hunt the value.

Behind all of the previous techniques, is simple but important principle - keep questioning the value of your choices and your assumptions. Question them deliberately and frequently.

Are your goals still correct? Are they delivering the right value? What could you do better? Are you learning the right things?

Seek out better ways of delivering, and ruthlessly cut things that aren't actively helping you progress.

7. Seek forgiveness not permission.

If you feel you should do something, do it.

In many organisations if you ask, you'll likely be told no. It's a default position, no-one's assessed it. If you just do it, you can prove the approach's value, and if you have to, apologise later.

I find this powerful in archaic organisations that aren't easily convinced to change.

The one caveat - think through any legal/ethical issues before you dive in!

Let me know how this worked for you.

If you try these suggestions out, I'd love to hear how you get on. I hope it's awesome, if it is great! If not, I'd love to talk about why. Tweet or email.

The right features aren't enough

Wed, 10 Jun 2015 00:00:00 GMT

A corollary to 'MVP A Child's Eye View'

I've been meaning to write this for a while (About two years!).

Three years ago, I wrote a blog post about my son's purchase of an MP3 player, discussing MVP. MVP - A child's eye view.

This is the corollary to that post, to explain why the right features aren't enough.

Good 'design' engenders desirability.

The short version, the MP3 player lasted about 9 months, and then was sold, the money put towards the iPod Touch, which two years later, is still the goto device for a myriad of activities.

The camera is relegated to mum's purse, for if the iPod battery runs out. The DS is relegated to a box in a cupboard, the computer is used grudgingly for homework (and is now an old mac). An android phone is an ongoing annoyance, and is driving a desire for an iPhone with the acceptance that it would need to replace the iPod.

I'll not downplay marketing, social proof or rampant consumerism, these all play a part in desirability. That said, I believe good design, in both hardware and software make a massive difference.

I was initially sceptical about whether the iPod would really give my son enough enjoyment to make the price tag worth it, however, almost immediately, the scope of usage expanded. Gaming was the start, then photography, then when we finally caved in social networking...Instagram, WhatApp and OoVoo allow him to stay connected with friends.

The build quality on the MP3 player was fine, ergonomically, it was OK, but not great, the interface however was appauling. Click regions so small you couldn't hit them, even with a childs fingers. Unclear interactions and navigation, meant it was functional, but a frustrating experience. Videos would play, but even supported formats wouldn't work all the time, music wasn't searchable, playlists were hard to create and maintain.

In honesty, I'm not sure that any of that trumped the kudos of owning an iPod as a reason for trading up. However, desirability of the hardware, combined with the fantatic usability of iOS are what have made it his main source of digital entertainment and communication two years on.

Writing this, and reading Kathy Sierra's Badass (which is a great read), I realised there is another aspect that shaped his enjoyment, self-actualisation. This is not limited to Apple, but the ability to explore new ideas, new apps, new methods of communication are designed in to modern digital devices, and it's this that makes them objects of desire, for what they facilitate as much as what they are.

(If this reads as apple fanboyism, it's not, I think Android, is a compelling platform, with an ever improving interface, and a similar ecostructure that allows it's users to explore.)

How to fix your postgres install when you've run `brew upgrade` without backing up Postgres data over a major version

Thu, 26 Sep 2013 00:00:00 GMT

Doh! Third time now. Seriously. I just don't notice that it's a version upgrade, and set it off. Then "oh *!#$"

Now, I know I can remigrate most of the stuff I have running, I also have backups I can pull, so it's not the end of the world, but it's tedious and something clicked in my brain this time...

Homebrew maintains older versions. (Unless you're a fanatical cleaner-upper). If you haven't run clean, here's a solution.

Make a directory to copy files to:

mkdir /usr/local/var/pgsql.old

Copy your postgres folder

mv /usr/local/var/postgres /usr/local/var/pgsql.old

Create 'new' postgres files

initdb /usr/local/var/postgres -E utf8

Stop the process

launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

There's a facility called pg_upgrade for this...but you need the old and new binaries for it to work! Yay brew not deleting old versions! The command looks like this:

pg_upgrade -b /usr/local/Cellar/postgresql/{old_version}/bin -B /usr/local/Cellar/postgresql/{new_version}/bin -d /usr/local/var/{old-data-dir} -D /usr/local/var/{data-dir}

If you set the folder up as above, it'll look like this.

pg_upgrade -b /usr/local/Cellar/postgresql/9.2.4/bin -B /usr/local/Cellar/postgresql/9.3.0/bin -d /usr/local/var/pgsql.old/postgres -D /usr/local/var/postgres

You'll then see something like:

Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is a superuser                       ok
Checking for prepared transactions                          ok
Checking for reg* system OID user data types                ok
Checking for contrib/isn with bigint-passing mismatch       ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 ok
Checking database user is a superuser                       ok
Checking for prepared transactions                          ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows on the new cluster                        ok
Deleting files from new pg_clog                             ok
Copying old pg_clog to new server                           ok
Setting next transaction ID for new cluster                 ok
Setting oldest multixact ID on new cluster                  ok
Resetting WAL archives                                      ok
Setting frozenxid counters in new cluster                   ok
Restoring global objects in the new cluster                 ok
Adding support functions to new cluster                     ok
Restoring database schemas in the new cluster
                                                            ok
Removing support functions from new cluster                 ok
Copying user relation files
                                                            ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    delete_old_cluster.sh

Restart postgres

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

MVP – A child's eye view

Thu, 23 Feb 2012 00:00:00 GMT

A little background.

Recently, my son decided he would like an iPod touch. (well, really, he wanted an iPhone, but he's to young for a phone...) We felt, if he wanted something that big, he ought to save for it to appreciate the amount of money it was. He had some birthday money saved and so the conversation continued.

Next question. 'So how much does an iPod Touch cost?'

He was surprised at the answer and we rapidly established he didn't want one £200 bad...

Trimming scope

After a conversation about the cost of things generally, we talked about what he wanted the device for. The reasons, were largely technolust and friends having them.

As we talked, what was brilliant, was he started cutting scope...

'Well, I don't need a camera - I have a camera, I don't need to get on the internet, I have a computer, I don't need to play games on it, I have a DS...' We talked more and he realised that as he has Ubuntu, an apple device didn't add any value. (No iTunes for linux)

In scope:

Play music
Watch videos
Look at photos
A big screen

Out of scope:

Internet
Games
Camera
itunes compatibility

So, what started as a £200+ requirement, became a £90 device, which had more memory, than the iPod, did video, music, picture and happened to also do audible, and had an FM radio.

I'm blogging about this, as I found it a useful insight into how MVP isn't that hard to get to, once you start looking at what the value of each of the requirements really are to the user.

Sometimes UX is like Magic Paint

Tue, 21 Feb 2012 00:00:00 GMT

Sometimes making a tough job easier is as good as it gets.

If you've ever had to paint a ceiling, you'll know it's not a fun job... Whatever you do, it's not going to be a fun job. As I was painting one of the many ceilings that need painting in our evolving house, I realised, fun isn't everything.

There is a great product called magic paint...(Other versions are available). It is simply white paint, with a pink tint, that fades as it dries eventually going white. The genius of this, is on your later coats, you can see where you've done.

It's still not a fun job, but it's a lot less painful than missing a bit and someone pointing it out later!

It set me thinking, some tasks we are asked to improve in UX can't be made fun, but making them less of a chore is still a big win.

Thanks to Mike Williams(@dokieboy) who's tweet prompted me to finally get this blog posted!

Building Communities

Thu, 11 Nov 2010 00:00:00 GMT

Building communities around your product is a really great way to grow your userbase and enhance your brand if you do it right.

Riverford really get this right...

My wife, son and I recently went to "Pumpkin day" at the Riverford farm that is local to us.

Wow. Really brilliant community building. Free entry, no overpriced nonsense, great easily accessible entertainment for the children, a box of (free) fruit by the door, A nice tour of the farm...I could go on.

What I found so inspiring was the lack of commercialisation of the whole thing. Enormous pumpkins were £2, the coffee was less than a coffee shop, there was a discount on all farm products on sale by default.

Everything was simply, here's what we do. No hard sell, just enjoying the farm for what it was...My son was really excited (and slightly incredulous) that he was allowed to pick and taste the herbs, straight from where they were growing.

I don't really have any more point to make than if you open your product up to people, in a genuine and engaging way, you'll enhance your brand, and possibly even gain new customers.

Compromise without compromising

Fri, 17 Sep 2010 00:00:00 GMT

You all know that feeling - something's got to give...Time, budget or features? Oh wait a minute...interface! That can give...our code is more important, that's what makes the product work, right? Well no. (And yes, but mainly no.)

The user (generally) only sees the interface, and has no concept of the code behind it.

I keep hitting this at the moment. Life isn't a green field project and it's inevitable you have to compromise, the issue for me is that UI / UX is often an easy target for 'not MVP' slashing. I see that's often acceptable, but sometimes it's a cut to far. This is for me where you have to choose your battles.

Where is the line?

For me, when I start a new project, I always aim for perfection. In the back of my mind, I am assessing where I'll pare that back to meet the inevitable constrains. I am also assessing a baseline of acceptable functionality, usability and user familiarity beneath which we cannot compromise.

The line is different for every project. I base this off the constraints and embrace change as it happens. This is really hard when it's a major change mid project, but things happen and sometimes you have to roll with them. (In my case, with accompanying grumbling!)

So how do you find this line?

Acceptable loss

I try to ask myself what is my motivation for arguing for this? If we lose this element, are we below the 'baseline' standard? Are we near enough the baseline standard that the next (inevitable) compromise will push us below it? Can we find a different solution that pushes us back up the scale of acceptable?

Sometimes, it's simply that I really like that element/feature/behaviour/colour. That's when I walk away...

Sometimes it's that I know a bar has already been set in the ether, that we will sink below if we cut something. This is harder, sometimes there is a compromise to be found, that still delivers enough that the UX won't be compromised, sometimes there isn't and you have to decide if you are better killing the whole feature than under-delivering.

Sometimes it's IE6. Check your logs, see how many IE6 users you have and if your client can live with loosing X% of non-upgraders. If they have corporate clients, often this simply isn't possible. In this instance, I've started to favour an IE6 specifically compromised approach. Make it minimally functional and that's it. (Or accept you need to double your project cost!)

Is massive improvement enough?

Often the starting point of a project is so bad, that you can't really help but improve it. The issue for me then becomes one of setting expectation for ongoing improvement. UX / UI (certainly in the agile context) is an iterative process and when you release, it's NOT done. On the other hand, I have to accept that a great improvement, is probably a totally acceptable compromise for release one.

Make friends not enemies.

I am not an island. I've found that if I can get people to mind-shift and understand the value of UX, I have an incrementally easier time when the next compromise has to be discussed.

My stance is to champion quality. I am not interested in glossy UI. (Nice though it is) I am interested in delivering a product for the client that turns users into advocates. I believe this is done by removing friction from their experience, making things easily usable and not forcing them to learn new interface models when the existing ones aren't broken.

Live with it.

I have to compromise. You will (unless you are omnipotent) have to compromise at some point. I try to compromise where it's OK, stand my ground, where I know I really should, and choose my battles everywhere in-between. If you battle over every last thing, you'll make enemies, not friends. This will make your life harder, I know, I've tried it in the past!

Something I've seen a few times recently is the current shift to mobile devices. Mobile devices offer additional functionality such as location. Here the compromise is dangerous. You can easily deliver a 'broken' experience by not embracing the technological expectation of the users. 'What, I can't search near me? Lame.' I also feel that just because you can, doesn't mean you should. The 'we need a mobile app' mentality only holds up, only if you really do. I try to persuade the client to think about their user, what is the mobile app actually allowing them to do?

Reality is that it's the new hotness and so you'll probably not win this one ;-)

Don't beat yourself up.

At the end of the day, I find, I live with relinquishing things and compromising by knowing that I've fought for the important stuff, and I hope that this communicates back to the team/client that I have the project's best interests at heart.

Agile UX and Design - What's in it for me?

Tue, 20 Jul 2010 00:00:00 GMT

A friend nudged me on twitter to write a blog post about this, which was great for two reasons, firstly I was having a bad case of writers block (or at least procrastination), lots of things had made me nearly write a blog post, but not quite catalysed.

(UX of Riverford's new store, Should you try and make your copy SMART? etc.) Secondly, we are going to a UX retreat this weekend, and I think this might be a topic I want to discuss there, so thank you James for the timely inspiration.

Creatives and agile – The smell of fear...

When I first started at Eden; in the designer part of my role, faced with an agile developer asking me to commit to short iterations, my gut instinct was panic. Not because I felt incapable, but because creativity isn't something you always have, or can turn on, on demand. This was of course not the right reaction, or even justified. It was however, I suspect what most 'creatives' feel when faced for the first time with seemingly short iterations.

Reality Check

It's true, creativity waxes and wanes, but we cope with this all the time.

What are the tricks we use to do this?

Limiting the fidelity that we work at (In the traditional design world, Marker visuals, Lorem ispum, Photoshop comps, low-res thumbnails of photos)
Trying our ideas out as quickly as possibly and discarding LOTS of bad ones. You still scribble stuff, right?
Slowly refining and enhancing ideas and designs (thumbnails, to mockups, to proofs etc.)
Working with a team to get things done quicker
Only presenting part of the solution (e.g. We need the Brochure first, lets start there)
Getting feedback from the client and refining at each stage.
Building some extra time into the deadline to make sure there is 'wriggle room'

Hmmm - Maybe it's not so bad... Breathe.

You are already doing it!

Limiting fidelity, Agile Story Cards are a lo-fi method of capturing the idea of a piece of functionality.
Slow refinement - well that's iterative development
Working with a team - You are part of the team (and maybe have your own team as well - double win!)
Only present part of the solution - Work on a small chunk of functionality at a time
Getting feedback early - Weekly (or even daily or less) releases mean constant feedback.
Wriggle room - You should be in the planning meeting and state if you can do it in time.

But What's in it for me?

Shorter time-frames add focus. Given longer, I won't actually get more done, I'll procrastinate until I have a looming deadline, then find focus.
You'll have happy customers At the end of the day, we all want to deliver things customers are happy with. The problem is that at the beginning of most projects, the customers think they know what that is (and don't) and you think you undertsnd what they want (and don't). If you do Agile design right, you can combat this by really establishing what the needs are and then delivering a solution to the real problem.
Built in Fail. Sounds odd, I know, but it is liberating to acknowledge that you don't have a crystal ball, and it's not reasonable to expect to entirely acurately understand every problem and therfore, it's impossible to provide a correct solution first time, every time.
When you do get to see the whole, you have something real to design If you've iterated on your project, and kept the design (skinning) to a minimum, you can at the last responsible moment, start doing PSDs with the benefit of a working prototype which removes the 'we'll probably need a twitter widget here' page filling that creating PSDs often induces.

What techniques can I use.

This is a blog-post (or series) in itself. However, we've been trying out Story Mapping, and Sketchboarding, both of which we've found pretty helpful.

My main tips are:

Pens and paper Scribble your ideas, perfect drawing is not required (anyone can draw a box!) and use it as a tool to facilitate conversation about your ideas.
Conversation You need to talk. To your client, to thier stakeholders, to your team, to your developers and ideally along the line, you should talk to users (a lot).
Avoid Photoshop early on We've found that photoshop gives a false impression of a finished solution. Unless your stakeholders need Photoshop visuals to get buy in, we say avoid them. Try and steer them towards wireframing. If they need them for buy-in (which many do) be very clear that they are an indication of what could be. Nothing more.

Caveat lector

No amount of Agile allows you to not have to think. You still need an overview of the whole project in the back of your mind, when you are working on a small piece.

You'll have to have an understanding not just of the problem, but of the solution, the technologies, the implications of decisions on the team and budget.

You will have to push back against developers and customers from time to time. That's OK. Defend the things you genuinely feel are required.

You are part of the team

Agile is all about collaboration. You need to be one of the team. Seriously, the siloing of creative vs. technical is just rubbish. Developers are unlikely to have your skills and vice versa. You will learn and teach a lot (as will they). Share your skills liberally, and everyone will benefit.

I think there is a whole post in how you get 'on the team' and as it's late and this is already a long post, I'll come back to that another time.

Interface should indicate behaviour

Thu, 06 May 2010 00:00:00 GMT

OK, so it's sad to admit, but I think about user-interface quite a lot outside of work. (And should write about it more often, but that's a different issue!) We recently bought a new house, which is great, but like a UX project, coming to someone else's work, you suddenly realise all the things you take for granted as 'just right'...

The cupboard handle that prompted a blog post

There is lots of built in storage in our new house, which is great. However, the handles on the cupboards look exactly the same as the door handles on the actual doors...Sounds correct, right? Good design, giving a consistent finish.

The only problem is that the cupboard doors don't have latches, they have magnets and so are a pull handle, the main doors are turn and pull as they have mortice latches. The cupboard door handles still turn, so I find my self turning the handle, finding it stiff and wondering why the door isn't opening with a click. I know in the back of my head that this isn't the behavior as I've learned that through repeated annoyance, but I still do it wrong more times than right.

The thing this triggered in me was that interface should indicate behaviour, above design consistency even. I'd rather have different cupboard door handles (that look nice in combination with the main door handles, aesthetics being important as well!) but that clearly indicate the behaviour to be a pull, not a turn.

Things that look simple and 'just right' are only that way because the person planning it did a good job

We were spoilt with our last house, and I didn't realise it. My father in law is a retired electrical engineer and kindly helped up plan the electrics in our previous house. (which needed a total rewire) I have to say, at the time I thought the number of light switches he was suggesting seemed overkill. Why would I need to be able to turn the downstairs light off from upstairs? Why do I need a pull cord over the bed to switch the bedroom light off? Surely it's common sense to have enough power sockets?

No so. Our new house, I have to walk downstairs to turn the light off, I can only turn certain rooms lights on from one side, so I have to follow a specific route in the dark to get to where I want to go. (not the shortest route obviously) If I want more than 2 appliances plugged in, in any room, I need a trailing socket. Now, none of these things are life-threatening, or even seriously annoying, except when you have come to expect that level of thought to have gone into something, you miss it when it is not there.

The lessons for me here were 2 fold. Firstly, that things that seems obviously correct, often aren't as simple as someone made it look. Secondly that craftsmen are everywhere. Unassumingly doing a good job, and not shouting about it.

Finally, I'd like to say thanks Bryan for the excellent planning of our electrics. I only now understand how clever that 'simply right'-ness was!