Ross Popoff-Walker wrote a properly ranty blog post yesterday entitled ‘UX Design at Digital Agencies is F*cked‘ in which he discussed the typical waterfall methodology utilised by digital agencies he’s worked in.
Most of us with any agency experience would have no doubt been nodding in agreement to read:
Big digital agencies especially, will kick off a project with a â€œdiscovery phaseâ€ (which may or may not actually discover anything), and quickly jump into a waterfall-style design process of UX sketching, wireframing, and client meetings/approvals. Then after many (many) rounds of visual designâ€¦ and only thenâ€¦ will agencies start to move into the development and tech stage. Only after every pixel has been pushed and use-case documented, will something be made that is working and actually functional.
Developers and tech leaders intuitively get the problem with this. Websites (or anything digital) are not buildings, made the stand the test of time without change â€” they are meant to be tested and iterated, and improved continuously. But in my experience, it has never made anything of real value to a client.
Ross goes on to advocate that agencies take up the Lean Startup methodology widely in use amongst start ups and some of the more forward thinking and/or buzzword aware larger companies. I concur. This is indeed a fine and very user focussed way to approach a project.
However, Ross glosses over the reason agencies work this way (‘comfort, dogma, and the ease of billing clients’ he suggests). I think a lot of agencies want to work in a more Lean or Agile way (and some attempt to do so), but the nature of the agency/client engagement will have to change substantially in order for this way of working to become widely adopted.
A few things happen when you hire an agency.
Firstly, the client effectively outsources the work. They create a separation between themselves and the people who are doing the work.
Even the agencies who work most closely with their clients (and by this I mean properly in each others faces physically or virtually ALL the time). This creates a different dynamic than what you get in an inhouse team. There is an “us” and a “them” and they have very different realms of expertise and knowledge and often not a great way of combining these two sets of knowledge to make a great product.
The lack of integration between the company who needs the project done and the company who is doing the project creates a very different shape to a typical (effective) Agile or Lean team, and it makes it difficult to work effectively.
It also introduces another ‘customer’ to the mix – one that is not the end user customer, but one who will sign off the project and pay the bills – so, probably, a more important customer to the agency than the *real* customer that the project is being created to serve.
Complicated huh. Makes it hard to focus on what’s really important when there are actually TWO things, often in conflict, that are important. Agencies will always preference making their customer happy over making the customer’s customer happy. That’s understandably, but it doesn’t lead to good project outcomes.
Secondly, when the client outsources the work, they feel as though they’re outsourcing the risk.
They effectively pay a premium for an agency who knows what they’re doing to do that thing well. It tends not to play well for an agency to then spend the duration of the contract being actively uncertain, making hypotheses and validating them, using the client’s money to ‘learn’.
This, traditionally, is not what we pay a top class agency to do. We pay them to know stuff and to get stuff right, and to be the people we blame if it doesn’t work out well. Until clients get comfortable with this (will they ever?) it will be difficult, nigh impossible, for an agency to be properly Lean or even agile.
Thirdly, when you’re paying an agency a lot of money (and you usually do), you want to feel confident about what you’re going to get when then money is spent.
This is why clients are so desirous of spec work in the pitch process – it makes them feel more confident about what they’re going to get for their money. Getting them to let go to spec work in the pitch is hard enough, how much luck do you think the Biz Dev guys are going to have selling Lean, where all we have is a Build, Measure, Learn process that admits we don’t really know anything for sure, and the possibility of pivots along the way. (Not to mention that most biz dev guys probably don’t have the first idea what Lean is and have the wrong idea about Agile).
No one ever got fired hiring a big name agency to do waterfall, complete with functional specs and three different visual design variants for the marketing team to choose from. They probably didn’t get a good product at the end of the process either, but they got a thing that looks as though it probably took as much time as the agency said it was going to take, and looked kind of pretty, and so they don’t feel ripped off and angry. And they won’t get fired.
It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker and many, many other inhabitants of agency world would like to work.
The agency model is certainly pretty broken, but both agencies and – I’d say more importantly – clients need to take responsibility for that, and take both action and a little risk to help mend it.
41 thoughts on “Client/Agency Engagement is F*cked, Waterfall UX Design is a Symptom”
Also: the economies of running an agency (spec work, cyclical pressures etc.) seems to bias results in a certain way and certainly influences the Principal Agent Problem that is at the core of this mess.
@Lisa first of all: Great post and I genuinely always enjoy reading what you write, because it’s honest and relevant.
I recently had the same thoughts after turning down a full-time job at an agency that promised the world to me, to which I responded that I don’t believe they are any different to the ‘others’.
I think that the willingness to adopt agile methodologies or lean business approaches also depends on the stage of your client’s business. I recently started working (as a consultant) with a lot of start-ups (that are at Seed Stage or already completed their series A round) and I identified a real difference in attitudes and behaviours compared to larger organisations, because failing to do things ‘right’ for the people that are using their product or service is a death sentence for their business. Businesses at this stage truly understand the value of time, which means they canâ€™t really afford to waste time â€˜fine-tuningâ€™ a feature that not one of their customers has seen or approved yet.
Of course working with start-ups involves higher risk and often produces less revenue in the short run, but I personally prefer sweating blood for a company that literally is holding their customers hands, than wasting my time and efforts to change some middle managers attitude, when I know she/he doesnâ€™t care to give one drop of blood to her/his employerâ€™s customer.
Hat off, once again, to a great post that got my neurons firing! Thanks!
I think it’s always worth remembering that agile and lean methods – or any other for that matter – are equally prone to these issues. How well a method is applied is as critical as whether it is used in the first place. I’ve seen dozens of agile, lean, integrated, multidisciplinary projects go disastrously wrong too – simply because the teams involved ran them badly. In fact if there’s one common pattern above all that I’ve seen agencies mess up over the years it’s the ‘impose’ problem: forcing a methodology on a client when they should have invested time figuring out how to work with them successfully.
I’m often reminded that architects have to design far more complex (and high-risk) things than most digital projects, but never get to design them as they get built. Interestingly, the only ones that use a ‘lean’ equivalent are the trashy mass housebuilders – solving design problems as they build. The majority use other techniques – like modelmaking and pre-visualisations (read: prototypes in our world) as their problem-solving tools. The buildings with the most talented architects behind them end up as landmarks that are admired the world over and enjoyed for decades, and they have few if any problems with how well they function.
But then it is often said that no-one gets to be a great architect until they’ve ‘been at the hard end for 20 years’. And that’s after 7 years of formal training.
I’d suggest – while agreeing with you too – that some of these issues simply come from the inexperience of a very young industry (at both client and agency ends)? Or maybe I’m just getting old ;)
Very astute comment Mark. People over process. There is also the problem of complex, integrated global campaigns – it may be easy to adopt an agile methodology for a very focused project, but it becomes very difficult when you start talking about communicating ideas and stories that span multiple touch-points.
Depends on what you mean by Agile. Also, Agile is specifically “designed” to handle complex adaptive systems (where traditional methodology has been such a colossal failure). Granted, the Agile movement has had growing pains in terms of applying at scale. However, there are new emerging techniques for scaling Agile up. For example, see http://scaledagileframework.com
Comparing architecting/constructing buildings with software dev is the classic examplar of misunderstanding software methodologies, Lean/Agile included.
great comment Wilson
change an agile work is sometimes no work (and no money). as an agency you need to understand the open an agile nature of the web, but most importently you need to undersand what is the best way and the right steps to take youre client there.
“Iâ€™d suggest â€“ while agreeing with you too â€“ that some of these issues simply come from the inexperience of a very young industry (at both client and agency ends)? Or maybe Iâ€™m just getting old ;)”
History indicates that you are right about this…
if one is benevolent because of inexperience, otherwise it can be said it is because a young and popular industry offers opportunities to all sort of amateur, improvised practitioners and quite a few legit quacks :)
Every once in a while I encounter an article that eloquently explains something that I thought and felt all along, but once it gets organized as clear statements like this it knocks me over.
It’s also incredibly important to remember that most digital agencies are, in fact, owned by large, multinational holding companies — holding companies that are public entities with stock holders, and thus the added, irrational pressure of share value and stock price.
The agency billing model, and thus its structure and the way it does work, is held hostage by this reality.
Then, think about the digital arms of traditional agencies — OgilvyOne, Proximity BBDO, Tribal DDB — and realize that working in anything other than waterfall would require the entire agency (digital, print, media, pr) to fundamentally alter the way that it works and bills.
Long story short: it’s never, ever going to happen. Never.
I agree that the billing model is definitely an obstacle, a huge one even.
But where there’s a will to work differently, there is always a way. I have seen this personally, having worked in an agile/lean way at an agency that is limited by the very same structure you identified. So, it can be done.
Don’t say never.
I remain unswayed by vague anecdote, sir. I’ve worked in and with agencies (digital, and digital within traditional) for 13 years.
I agree w/ Jason. Never use an extreme commitment word (except in this sentence). :-)
I think clients of agencies will eventually come around, as they themselves are forced to become more Lean/Agile. Afterall “software is eating the world”, as Marc Andreessen wrote.
It just takes time (even in non-agency s/w dev houses, which surprises me to this day, after 15 years in the industry).
Another issue I’ve observed in working with agencies to help them adopt more lean/agile methods is the number of people involved in writing and approving contracts/SOWs. A lot of agency process is baked in at an operational level in Legal, Finance, and HR that is resistant or impervious to what they see as some risky “flavor of the month” new way to work. In many agencies it takes a long time to turn that ship. What does seem to work is setting up a separate team structure or even a separate business unit, potentially with its own P&L, that scopes and manages projects and teams differently.
Good positive suggestion. I’ve had experience of this on a particularly autonomous project within a large business, with it’s own lean team, processes and hosting. If successful, the lessons learned can ‘cascade’ to the rest of the organisation.
Ya, the crux of the issue to me (from an outsider’s perspective) seems to be the barrier of convincing clients to switch to a form of “Agile Contract” (which exist), since that forces a new math on ROI calculations, and new structure on the legal department.
Great point of view.
I think this also explains why UXers often struggle inside agencies: A focus on the user and a desire to ask questions or conduct research can threaten the desire of agency executives to protect the agency’s image.
Inadequate budget or human resources are also constraints that can deter from a fluid relationship. When half of the agency’s team is stretched across other projects that they hide from the client, they aren’t present to collaborate. Same goes for a budget that doesn’t accommodate it.
One question is how the big UX firms deal with this dilemma – my finding as a UX consultant has been that when teams hire me, they know what they’re getting and nobody is disappointed that I don’t claim to know the answer upfront. I assume, too, that a firm that stakes its claim in research and questioning doesn’t disappoint the client when they ask questions and seek collaboration.
Completely agree with your three points, Leisa, and I think this is a problem which affects folks beyond pure-UX agencies. At Future Platforms we did a mix of pure design and design+development projects. We found the latter to be more problematic, as measured by looking at stats for profitability and overrun.
I think there’s an intrinsic subjectivity to many design projects which plays in the agency’s favour here. Once you get into delivery of a full product, you hit a load of real-world implementation details outside your control, and what you’re delivering can be measured and evaluated by the customer more quantitatively.
We felt that the major problem was not working across organisational boundaries (large businesses do this internally, after all), but the contractual relationship between client and agency. Once you’re locked into fixed-price, fixed-scope, there isn’t much room for iteration unless you have a customer who’s comfortable with regular change requests, especially those which get more frequent towards the end of a project lifecycle when budget is running out/run out.
We experimented with target cost contracts (which I feel could work, but we didn’t do a great job of applying); pure time and materials (which pushes all the risk onto the customer), fixed price, and sometimes a mix (e.g. fixed discovery phase, followed by fixed design+build; fixed discovery phase followed by per-sprint billings; etc.) There were others we never got around to trying (e.g. Jeff Sutherlands “Money for nothing” proposal). In the last few years we found that an increasing number of customers were quite keen to work iteratively and collaborate with these models – including some quite large businesses.
I’m also not convinced it’s purely an issue of the experience or characteristics of the team; I’ve not seen any data to suggest that more experienced teams do better at this sort of thing, and I’d imagine it’s the kind of thing which people like the Standish Group might look for in their research.
In 2010 I joined an agency that was making an honest push towards agile methodology. When I left 2 years later, this was still in the pre-discussion phase.
As you say, there’s a pervasive culture of value-perception and -attribution in many agencies that completely rails against the ‘fail early, fail fast, fail often’ pragmatism that developers in particular find so much more valuable in the long run.
You make a good round up of the economic factors which make the psychology so difficult to shift. The fact that the client is paying top dollar implies that we must maintain at least the illusion of infallibility, at which point the notion of experimentation â€” or a process that presupposes mistakes â€” is abhorrent.
The real tragedy is the situation in which the al- valuable face time with the client â€” the moment during which ideas are iterated, presented, and given the go ahead â€” is often spent painstakingly pixel-pushing to produce elaborate JPEGs which define the agreement: the tasks of determining that the technology necessary to breathe life into said JPEG does not exist, the user journey described is logically incoherent, and the minutious graphical detail is impossible to replicate procedurally based on dynamic input: these are notions that despite their crucial importance to a project’s success and repetitious eventuality, are still fundamentally too embarrassing for a top-notch creative agency to have at the all-important conceptual phase of a project’s development.
Ultimately it comes down to an inability to accept that sometimes the infallible image you need to project to your clients is not the one you can rely on internally.
EXCELLENT points. Especially this:
Sad, but true.
But I think we are better in teams. Whether you’re UX or pure Visual or Tech I believe we’re stronger, more creative, more motivated and deliver higher quality work in a team. Most of the top talent don’t want to be ‘salaried’ these days, so we need to find ways of being contracted to work as teams without falling into the pitfalls of the ‘deliverables’ agency world.
It’s particularly important in the Tech world to work alongside people who have a similar approach or culture. Pair programming with like-minded folks produces a quality project and provides an investment in future technical debt in your product.
I’ve seen T&M contracts with a small collective of people – sharing overheads in a co-op ideally – work really well. Go Freerange have a lovely, almost utopian business model based on T&M contracts and quality, kick-ass code. And it’s working.
I don’t agree with the common view that a pure T&M project “pushes all the risk back onto the client”. We need to stop looking at it like this. It’s like saying that hiring an in-house team is a risk.
IMHO, you need these things to make T&M work:
* In your contract, allow the client to fire you every week if they’re not satisfied. And vice versa.
* If you must build a release plan or project plan, make it high-level and built around goals that can change by mutual agreement. There’s nothing wrong with planning afterall, but not in great future detail, and NOT when those plans can’t change.
* Be transparent and honest about your project challenges. You and your client both own theses.
A very interesting discussion that I have heard and participated in repeatedly over the past many, many years.
But rather than add to it again, I’m putting out a request to those of you with strong opinions and deep experiences.
I’m writing a book with some fairly established folks on the current state of the entire advertising and marketing industry and what we need to do to fix it â€“ mostly centered around what they box up as “digital.” Each chapter is being written from the perspective of agency and client side roles (e.g., creative, strategy, account management, media buying, head of the agency, branding, marketing, technology, etc) to form a manifesto.
All of us have a strong point of view about where and why things went wrong, what should’ve been done, and what still should be done to right the industry. We’re interviewing dozens of people who have been through it all before, but can always use insights, opinions, anecdotes, and well thought out ideas from others.
If you’re interested in participating (and feel you are qualified because of your experiences and your POV), please contact me.
Thought my required email address would be linked in the post automatically, not just my site. So to contact me, send a msg to: josh at heresy dot co or through LinkedIn http://www.linkedin.com/in/joshsklar
Your final point – that it takes a special kind of client to take the risk and do things in a properly agile way – strikes a chord. In half a decade or so of talking to clients about the pros and cons of agile and waterfall, we’ve found ONE that will actually take the risk. And that’s a risk with their money, fundamentally. It’s refreshing working with them, and we’d love to do more work in this way.
Simplistically I like to describe agile as – “we’re going to deliver something, at some point, and it will cost you some money”. When there’s a client / agency relationship at play, that’s always going to be hard to agree to.
As has been mentioned above, an agency has to figure out the best way to work with each client, not impose a process on them.
Great points here Leisa. Absolutely you have to find a way to work with clients that’s mutually beneficial as James points out. I’m interested in pragmatic approaches to this agile/lean agency dilemma. This is what we’re thinking about at the moment anyway. Is there a pragmatic (ie clearly not agile purist!) approach where an agency can ‘baby step’ a client into an agile way of working giving them some of the benefits without necessarily all the unknowns budgetary and otherwise. Great to hear if anyone has any success stories here.
I would start by Googling “agile contracts”. There are many great ideas on how to distribute the risk to both parties.
If nothing else, at a minimum, one should consider trying to break one large monolithic traditional contract into multiple smaller traditional contracts (with the same client). This will already increase agility and reduce overall risk.
Great points to make Leisa, and from Tom Hume as well. I’ve been looking for an answer to a similar question for a while:
“How do you run an agile project when the scope and the price are fixed?”
That is the crux of it from an agency point of view, the vast majority of project briefs have a fixed price to produce a certain thing.
We are an agency that do UX/accessibility consultancy (user research, design & testing) as part of client project teams, and full design & build projects for clients. The consultancy side works fine in agile projects where we are sending people in to be part of the team.
However, doing a full design & build project when the scope and price are fixed,
you can apply some techniques, e.g. scrums, but you’re really working on a staggered waterfall approach.
Coming from a user-centred-design approach we haven’t had a lot of the issues Ross rails against, such as fidelity of wireframes. However, until people (i.e. clients) get used the lean/agile approach, I can’t see them taking a leap of faith with an agency to have an open scope.
I’ve thought the agency/client relationship has been messed up for decades, but don’t necessarily think the waterfall methodology is a symptom.
With true Agile methodologies, the entire team tends to interface with the client – which is contrary to why most agencies exist. If I (as a client) wanted to participate in every aspect of the project – I’d manage the project myself & select my team myself.
I don’t understand why agencies think I’d want to interface with their developers, designers, and IA’s – many of whom don’t speak in a professional way, many of whom don’t dress in a professional way, and many of whom are precious about their ideas.
In fact – if I was a client – I’d feel inhibited to give frank feedback when the 22 year-old who actually put all the work into creating it is in the room presenting it to me with a smile.
Part of the reason I’d hire an agency is because I don’t have the time to manage projects myself. I don’t want to just end up with a site without documentation (and to be clear, TRUE agile development doesn’t have documentation) In the same way I wouldn’t want to buy a refrigerator without manuals. If I’m buying a website – I don’t want to necessarily be a partner with you – I just want you to help me choose the features/ finishes/ etc. that would work best for me.
Overall, I’d say about 20% of all projects assigned to an agency would benefit from being run in a more agile way – but that leaves 80% of projects that would run better using a waterfall methodology. I mean who would run an email campaign, or banner campaign as an agile project? Once you start using different methodologies with the same client, it starts to get confusing.
Agree with most of your post.
“TRUE agile development doesnâ€™t have documentation”
Not sure where you got that from. Agile does *not* have a tenet that says “no documentation”, rather documentation is weighted less than working software.
“80% of projects that would run better using a waterfall methodology”
Actually, most evidence points against Waterfall being effective in the software world (unless you are building the Space Station or something). Doing true Waterfall would mean writing a specification up-front (Big Design Up Front), which in most cases (creative in particular) is pure speculation.
It is a little-known fact that the guy who introduced Waterfall (although not by name) to the software world in 1970, Winston Royce, actually argued *against* how it was structured.
“who would run an email campaign, or banner campaign as an agile project”
The Lean Startup movement speaks directly to this issue.
Great post and the same goes to Ross as well.
This really is the problem space we have been working on at Made by Many for 5 years now and before we were cribbing from Eric Ries we were smashing together agile development and design thinking techniques and picking up the pieces. The thing is it is possible to work in this fashion with clients and agencies and it is possible to work on product innovation.
But there are so many barriers for it to be a widespread default. First for agencies it takes an amazingly long time to get it to work well and you need to change every part of the organisation from billing to legal, design, tech, sales. The whole thing needs to be shaken up. I can’t imagine digital agencies making the 5 yr effort we have to reach this point.
Neither do they have to change. The dirty secret of the advertising and even the digital advertising industry is they take orders for advertising “I’ll have one 30 sec tv spot, a Facebook tab, a side of banner ads and do you have anything viral?”. As people have mentioned this commoditised business doesn’t need a new agile process. The problem is applying the same methods to product innovation and UX problems. But this is not the business they should be in and you shouldn’t order your UX from there.
But this isn’t a client issue. We have met loads and work with some who don’t want to outsource, do want a real partner, are in it for the years it takes to make a successful product, do understand its a learning process. It is a huge education program you have to invest in to help them and it requires breaking old habits but there are plenty of great clients out there who have gone through the old way and hated it. It isn’t all of them but its enough. Frankly the clients are more advanced than the agencies in most cases.
Because I like pragmatic advice, here is mine if you want your agency to really get lean/agile
1. Never, ever, ever take a fixed price fixed scope build project. Non-negotiable starter.
2. Talk about Agile from the very first meeting, say this is how you work and why it works. Give clients the chance to self-select out.
3. Strike a bargain with client, if things are going to change allow the client to change their kinds as well. Agencies usually hate this but you really have to embrace it.
4. Don’t take orders for solutions, work with the clients on their problems.
5. Hire the best possible people who really get it and can only imagine working this way.
6. Hamstring yourself by not knowing how to do waterfall so you are not tempted to take any other type of jobs.
Sounds really basic right but it comes down to conviction. You have to be willing to turn down lots of money for work that doesn’t fit.
PS +1 for Go Freerange. Awesome.
PPS this debate isnt worth having without mentioning Jeff Gothelf’s presentation Getting Out of the Deliverables Business. Buy his book as well.
I’m definitely a member of the choir here. And this was definitely a factor (among many) in why I left consulting to go in-house.
Initially I wanted to point the fingers at the consulting companies for doing it wrong, but I realized, wait, they want to do it right, but they are largely subject to their clients’ approaches, and by and large, clients (particularly those that can afford nice consultancies) are hierarchical bureaucratic organizations, and those organizations require certainty in their actions, and adopting an iterative/Agile/Lean/smart approach freaks them out, because it requires them to give up certainty of outcome. Now, I would argue that what they’d get is a higher probability of ultimate success, because the design team will have the opportunity to intelligently iterate toward the real problem, but that’s not how these clients view the world. They buy consulting services the same way they buy pencils.
There is an underlying issue here which noone talks about. It is very popular these days to bash Agency work and how it does not function well (on web projects). Noone talks how did it come to this.
It’s simple – Agencies are doing (well, trying to do) more and more what SHOULD NOT BE AGENCY TYPE OF WEBSITE. What is happening is that clients see all those magnificent projects out there in the world, Facebook, Amazon, Groupon, Twitter, LinkedIn, Instagram, … and they want to do such projects. Then they hire and Agency to do it.
But what is common about all those big projects which run the internet nowdays is that they do not have an Agency behind them – they have their own dev teams.
And this is where Agencies fell into trap – they started doing projects which should not be outsourced in the first place. From this all the confusion comes. Agencies are good at one type of websites (company websites, small brand pages, even to a certain degree some web shops, …), but they cannot be given a job to build “the next Twitter” or “the next whatever”.
For example – nike.com – is the best case for an Agency site. That should be ceiling of complexity an Agency should do. It’s a cool site that displays something, has a shop, has some cool things, and that’s it. There will be no iterations of design within that site, no A-B testing, no upgrades. Site will run its lifespan in a few years, and then another Agency will be hired to build a new one. Period. Take a look what Fantasy Interactive is doing, level of projects they are doing (and they are one of the best, if not THE best, Agencies in the world). That should clear things for everyone – those are fire & forget projects. They make them, they are pretty, and they move onto the next client. Chances are once the project is launched they basically delete files from local machines and just forget about it.
tl;dr – Agencies are attempting to build sites/projects which should not be outsourced to them, hence all the drama.
Stuart’s list of do’s and don’ts is great, and Go Freerange’s low down on how they like working with people contains a lot of similarly logical requirements. Idealistic requirements, though. Great for a small agency, but I’m not so sure how it scales up. Are there really enough clients out there who tick all the boxes?
I think all good consultants need a split personality: one for the client and one for the user. All jobs are sales jobs.
Digital agency is largely a misnomer – as they are usually run by partners who come from a traditional background with little or no software or web development experience.
The result is that dev teams are often put in a category as a production resource rather than having anything meaningful or creative to contribute.
So you often end up with a digital team that tries to stay Agile working within a waterfall organization that only listens to one thing, client demands. You end up with alot of frustration.
Digital work isn’t about just looking good or creating something cool, it also has to satisfy a user need. And I find it unfortunate that users are often left totally out of the equation!
I am soooo glad that we are having this conversation.
I have been in the digital agency world for 16 years. Starting at Razorfish in 1996 and then my own agency The Groop in 2001.
I become so frustrated with this that earlier this year I started The Skool – to teach an Agile based UX approach that made more sense that what we do for customers.
All the points are right on.
An experiment I tried with clients has been a “fixed fee” variable scope approach – with the whole team working in Agile. Have had some successes and some colossal failures with this approach.
But the bottom line is that educating your clients is the first and most important part of the job.
Only that at a mid to large size agency, things are moving so fast and the people selling are not the people doing – that educating is near impossible. By the time you get a signed SOW it’s TOO LATE.
Education is the answer.
Leisa, thanks for writing about this!
After working in the digital space for 22 years, 12 of which in IA and UX, I put forward that the practice of UX is endangered just as it is at the height of popularity. And largely because of it.
It simply goes like this:
BIG AGENCIES AND CONSULTING FIRMS CAN NOT DO UX, AND WORSE, THEY OPERATE LARGELY TO DISTORT ITS NATURE.
Let me explain:
at some point in the 90s local software houses virtually disappeared (except corporations, that is) and big agencies took over most of the web development. How and why this happened would be very interesting to explore but for now let me point out that these newcomers to the scene were not employment agencies and they were not estate agencies… They were, and are, Advertising and Marketing agencies!
So A&M hijacked web development and years later, when the term UX became fashionable, they simply jumped on the bandwagon once again… and they tweeted about it, and they talked about it as if they knew what they were doing. Every quack in history has always loved a new hype, an exciting and poorly understood concept or technology, for they knew that they could squeeze money off it (radium docet).
At this time consulting firms also started to do some UX, just because they already had dominating commercial positions inside large corporations and quite simply could sell anything they wanted, as long as it existed and it was profitable. And for them too, there is nothing better of a vague, poorly understood technology (insert joke of your choice about consultants here, to substantiate).
So the answer is simply in their name, neither Advertising nor Marketing have the same objectives of UX. On the contrary, they are most often in contradiction with it.
Agencies, if you read their web sites’ About pages, are mostly concerned with “Branding” a term that evokes brainwashing, cult-like following, populism, fashion culture, superficiality and plain old lies (and sends me straight looking for the sick-bucket every time I have the misadventure of hearing it).
Consultancies, on the other hand, prefer to be bogged down in documentation, committees, hierarchies and power struggles than doing anything productive. Moreover, they are so slow that they still have to figure out Manslow, so it should not surprise anyone that they don’t really get UX. They have never provided much real value in anything, anyway.
UX is a mentality, more than anything else, the mentality of being on the side of users and listen to them and facilitate them in doing something that is ultimately useful for them, and if possible enjoy themselves doing it, or at least not be annoyed.
Agencies are in the business of selling stuff or convincing the masses of something.
Consultancies are in the business of selling themselves to do basically nothing.
Therefore neither of them can have a UX mind set.
They use flattery, they use psychological tricks, they even use technology and design for their purposes, they use persuasive design, but certainly they don’t do UX.
Occasionally some of them have even put together decent teams at some point but as long as they work for the wrong objectives, it doesn’t make any difference.
Talking about the UX for a new running shoes advertising campaign is as foolish as talking about the expressive dramatic qualities of a capacitor.
I disagree with Peter (very rare occurrence indeed!) when he attributes the fault to the agencies’ clients.
Yes, their clients are often know-nothing corporate dummies, but can a client that is sold snake oil be blamed because they didn’t know better? However foolish the conned, the responsibility remains with the con man.
Of course there are firms, both agencies and consultancies, especially among smaller ones, that are not like this.
But as far as generic statements go: until there is a change in business ethics, the responsibility to do real UX remains with individuals and with in-house team, because both agencies and consultancies are inherently incapable of it.
Comments are closed.