A human non-solution to scope creep

We’ve all experienced it: a project is halfway through, if not almost completed. Somebody (generally a wealthy client) wakes up in the morning and announces that it’d be great to add that “very simple” feature to the page, which of course means it has to be done no matter what, possibly by yesterday.

Somebody else says ‘Yes, no problem’, maybe out of true conviction that the request is actually simple (99% of the time it’s not) or just out of sheer fear of contradicting the boss/client/project manager.

That’s a scope creep, when something gets added at the very last minute and strong-arms its way in an otherwise well planned work schedule.

It’s also known in plain English as ‘disaster’, ‘finger-pointing’, ‘people quitting’ and so on, until the parties involved call their respective lawyers.

Of all the magnificent theories about how to avoid all this, I haven’t found one that actually works. And not because the theories are flawed, but because we are human and therefore flawed.

Here my solution, which is in fact a non-solution because it doesn’t involve any specific techniques or process (there’s plenty of it out there, from Agile on) but it just relies on my own experience and observation of human beings fretting around a project.

The idea to this post came on the train to London, on my way to an agency we’re working with. I was reading a blog about User Experience and Product Design. It’s an excellent blog written by a very good consultant and writer, Joe Natoli.

I got to know him through his blog and his video course and I have always thought that what he writes makes a lot of sense, especially when he talks about scope creep.

I couldn’t recommend it enough, it’s written in an entertaining, accessible English and it’s full of real life examples of Joe’s extensive experience, on top of his extremely good practical suggestions.
He’s so authoritative because of his experience in the field. He’s seen it all, and he shares it with us, for everyone to learn, change and benefit from someone else’s mistakes. O, if only everyone would follow such a wise advice…

And this is my point: how many people do you know that changed thanks to new theories?
Well, I myself did, and I’m sure a lot of UX designers out there got caught by an epiphany while reading UX books and blogs that changed their own mind set and workflow.

But let’s be honest, a lot of people don’t listen to somebody else’s advice, don’t want to change because they think they’re infused with wisdom and truth (it gets worse with age) and learn only the hard way, when forced to after a disaster.

They’re not all monsters, of course, maybe some are simply human beings used to do things the way they’re used to. Or maybe during their daily job they experience a lot of limitations we might not be aware of (everyone is fighting their own battle, let’s not forget that).

Whatever the case, only when it’s too late – and legal documents are piling up on the desk – these people start reconsidering the whole process in retrospective, looking for what went wrong.

That’s when they are at their most vulnerable and ironically open to suggestions, finally humbled or simply aware that they are not as perfect as they thought.

If you want to help your team, this is the moment to intervene and point out that you’ve been saying that all along, when you kept pestering people with catastrophic emails that nobody bothered reading. Yes, everyone will think you’re a ‘told-you-so’ kind of a person, but who really cares if you manage to make a difference in the long run?

This is the time for you as a UX designer to provide some data, prepare a quick presentation, a case study, a video, whatever you feel comfortable with, so to show how changing process – and specifically avoid scope creep like the plague -can help everybody next time around.

The downside of my non-solution is that it requires time. You need to allow time for people to digest your contribution, they need to see real value to it when they most need it and are receptive to consider changes (you also need to allow some disasters to happen, I can’t see any other way around it). This non-solution also requires that people don’t leave but stay in the team long enough to improve all together, and I can see how that might be a problem.

But if all goes well, and people are still there after the mayhem, you will see that, little by little, everyone will become a User Centric Design process advocate, and if not perfect (we’re human, after all), your team work will become much more effective, and possibly even enjoyable.

You just need to keep sticking: to your guns, and to your own ever improving team.

Ally with the clients!

Fellow UXers, have you ever experienced one or more of the following situations?

  • you work in a company where UX design is a fancy new name for the good old front end development
  • your strategically placed and colour coded post-its on the wall are considered paper craft (and there’s always someone suggesting you use glitter)
  • you dedicate at least 10 minutes of your day in telling someone what UX really is and why you’re pestering everyone about adopting it as a default process (that someone is generally somebody you told that stuff a couple of times already)
  • you did countless simulations, presentations, prototypes and guerrilla training on those colleagues and managers  who would listen (and nod in sympathy) but you haven’t managed to break the resistance of the most influential project manager who won’t budge about giving you even three days for research, let alone prototyping

If that’s you on your daily life at work and you want things to change, well, it’s time to call in the big guns: clients.

Next time there’s a pre-sales/kick-off/sprint planning meeting where the client is at disposal, try and be there and give them the usual speech you use with the aforementioned colleagues.

Bring sketches, wireframes, interactive prototypes on your phone, whatever you have in your arsenal to show the client what’s behind the scenes. The more colourful, the better, clients really are like magpies.

Not only you’ll convince the client of what a solid agency you are – “See how much thought they put into my product?” – but also you will have gained an ally against that obstinate project manager.

If you win the sales pitch, and you will, you’ll become the new salespeople’s champion, and they’ll bring you along in future pre-sales meeting, therefore triggering a spiral of UX awesomeness.

The more the project progresses, the more the clients will rave about the amazing process, will feel involved and listened to, and will send ecstatic emails to the less and less hostile project manager.

The more projects you work on, the more project managers you will convince, thanks to great feedback from clients, the more UX culture you will spread in your company.

And this is simply because clients relate to what we tell them, because it makes sense and it’s simple enough for a non technical person.

The clients, caught between hard-selling salespeople and obscure-talking developers, find solace in the plain, human language generally used by UXers and relaxes a little bit about the investment they are to make, confident that there’s somebody there who cares just about users and not only money.

And little by little, your company will convert.

Just be aware, its going to take a while: never desist.



Just a little less Agile. But only at the beginning

Just today I had a long discussion with a colleague of mine about Agile Development and UX. She has the non enviable task of re-writing the ‘company manual’, a gigantic (I imagine) collection of processes to be used in every department so to make sure that best practices are applied everywhere. Stuff like compliance to ISO standards and other obscure regulations, I am told.

Luckily, it’s none of my concern as a UX practitioner. Nonetheless, I was more than happy to help her understand what it is that we do all day with our post-it scattered all over the corporate whiteboards and walls.

After sharing the UX gospel with her, I explained all about research and strategy and I dutifully showed examples of personas, user journeys, wireframes and prototypes.

Next, came the unavoidable question: “This is all very good and it makes a lot of sense, but we follow Agile development. How can we fit all that stuff in a two-week sprint basis, so that we can produce small chunks of the product to show the client for revisions? We can’t employ time in creating the big picture and the go into coding, that’s Waterfall!”.

The debate that ensued was so long and passionate that I thought it would be a shame not to share its outcome with the world (I’ll spare all the ‘and so I said, and then she said’ and so on).

My pedestrian explanation of Agile and Waterfall

If you are reading this post, you are probably aware of the ongoing discussion about Agile and UX.

Just to give you a quick recap, Agile is an approach to the development of digital products that divides the work in small segments, called sprints. At the beginning of each sprint, the team and the client decide together what piece of the functionality will be delivered, for instance something like the ‘Login to the website’ feature.

Forgive me if I overlook all the details of this process – I won’t mention user stories or team velocity – you can find a lot of valuable material on line. The bottom line is, we use Agile to deliver something quick, to keep the client engaged and to avoid to build a huge application for months in the solitude of your office, then show up at the client’s office, present the almost finished product and then discover that the client is horrified and wants to change it completely. This last, unfortunate situation (disappearing for months to code) is caused by the Waterfall approach.

Now, please, please ignore the superficial words I used to describe both Agile and Waterfall. I’m not a project or SCRUM manager, I just report what I learnt on the job and briefly summarised using everyday language.

My proposal to mix UX and Agile

What I also see everyday is that UX and Agile struggle to get along, which is a shame, because Agile is good, real good.

I love working with a team of developers where everybody keeps the others up to date during the daily stand up. I also – surprisingly – came to terms with our project management software, whose UX could be highly improved (how ironic is that?) but it helps .

The retrospective analysis of the sprint is an excellent moment where to raise issues and tackle them, right away. Everybody works better, once you get the gist of it.

The biggest obstacle, here, is the time allocated for the UX part of the project, it’s rarely enough in an Agile environment, where apparently every attention is to development.

The only solution I see is to use a hybrid between Waterfall and Agile. What I see working very well is to allocate enough time to UX practitioners to lead the strategy and design phase, so that when we are ready to go into development the whole project is well scoped out and documented. Honestly, it doesn’t need more than that. And if the word ‘documented’ sounds like pages and pages of specs and flow, well, it doesn’t have to be.

Call it Sprint 0, Initiation, Discovery, whatever you prefer. I honestly don’t care about being etymologically correct, what I do care about is having time to dissect the problem the client has and come up with a solution that makes the users and the stakeholders happy. And also developers.

Whereas Agile is all about these famed small chunks of functionality, I see that developers work better when they have the whole picture clear in front of their eyes. This is also the reason why I always want to involve developers as early as possible in the design phase.

Do a stakeholder interview (and other UX treatments) to yourself

As you may imagine, I’m using WordPress for this blog. The theme I’ve chosen is Twenty 15, the latest from the Twenty Something family that come with any WordPress installation.

Twenty 15 pretty great, to be honest, but I’d like to create something truly mine. I’ve been creating websites for clients in WordPress for years in the past, after all, so shouldn’t I create my own custom theme, all responsive and shiny, with a nice looking logo that reflects my ‘personal branding’ (as recruiters put it)?


Like many UX practitioners these days, I generally bore everyone* to death with the usual rosary of ‘Stakeholders Interview-User Research-Personas-User Journeys-Sketches-Prototype-User Testing-Do it again a few times’ and so on.

I believe it’s about time I bore myself to death as well (just joking, of course, I love doing all these things).

Here’s what’s going to happen. I am about to create my own portfolio and I will treat it as a normal UX project for a client. A little Multiple Personality Disorder will come in handy, as I will act both as a product owner and designer, interviewing myself and designing things for myself that I will then present to – guess who? – myself.

I think it may be interesting to document the whole process and share it here with the world. I’d love to hear comments from the world, as well.









* By ‘everyone’ I usually mean apprentices assigned to my team. I have the privilege to work with bright, young minds who never heard of these concepts before. After having received a few blank stares from their wrinkles-free faces, I now have perfected the combination of words that entertain them and let them memorise things otherwise obscure.

I use the exact same words with clients, and they love it.