Consulting – is there a better way? or “Where are all the designers?”
How did I get here?
Not too long ago, there was a discussion here on SCN that triggered me to respond with one of my usual longish answers… On Designers & Developers
Graham has posted another blog entry looking at SAP’s BUILD tool too, which is also relevant to the broader discussion and interesting in its own right.
Graham’s original post was really a discussion around the communications and working relationships of designers and developers. I’d say it has become and will continue to be a very pertinent discussion point in our world for many years to come. You could argue the engagement of designers and developers should have been very well established long ago in our industry, and in 2015 we would have much more pressing issues to discuss… Sadly not. The combination of designers and developers working together forms a massive foundation for broader UX considerations.
I want to focus on a key aspect of the designer & developer relationship that triggered my response – that of how the world of consulting, specifically SAP consulting, approaches this challenge.
From a broader perspective, I’ve worked in consulting for a long time now and up to very recently (i.e. 2months ago) never really experienced any proper engagement between a designer/UX consultant and the development team.
A better way?
If you have ever worked in an SAP consultancy or in a customer using an SAP consultancy, you will have noticed (if you bothered to look around) the distinct lack of designers available as resource to support any development effort. My experience is that almost zero thought is given to the broad UX topic when SAP projects are initiated – UX just “happens”. I’ll quote my own answer from Graham’s post here, to summarise the situation again:-
Consultant – “we’ll have a designer working 3 days a week for 6 months through the design/build phase, to ensure the developers are meeting the overall UI/UX guidelines and the app delivery is consistent with your user’s requirements”
Customer – “sorry no, we don’t want to pay extra for someone who isn’t building.”
6 months later…
Customer – “why do all of our app’s look like they’ve been built with the ‘data goes here’ design approach? They’re horrible, we won’t pay until they’ve all been changed and look better.”
In that post, I suggested consultancies need to be “smarter” in how they engage with customers and ensure proper design consideration is given to the solutions delivered. There is a massive responsibility on both consultancies and customers to work together, better when it comes to UX. But here comes the challenge I outline above – that old favourite of cost.
We exist in a paradoxical world where customers expect solutions to look and feel amazing and have intuitive, forgiving and rewarding UX’s; whilst they typically also want to see that solution delivered by the smallest possible team, hopefully at a very low day rate, in the shortest possible time. Compounding this, there is still a broad mentality on the consulting side that focuses on “billable work”. They appear to struggle on how to accommodate a function (designers/UX consultants) who don’t appear to have a clear route to revenue generation.
The model is broken.
You could argue any current SAP project will have a vast proportion of its deliverables heavily in the UX camp. How the end result is measured will often come down to whether the end users like it and use it. Or not. To achieve that, investment in UX considerations up front are a must and yet they are often barely an afterthought.
Call to arms
It’s not complicated. I’m not suggesting a completely new methodology for delivery. I’m not advocating a 6-month engagement with Saatchi & Saatchi before you even consider mocking up your first PO Approval app. All I’m proposing is a sensible approach by both consultancies and customers.
If you’re a customer:
- Ask your consultants about their UX capability, ascertain if it is a key value in how they deliver.
- Invest time with their UX consultants and designers to share key goals.
- Discuss how their resourcing model works to support this and what it means in terms of timelines and costs by all means but please, please, please don’t just chop out resource simply to cut costs. You WILL regret it. UX focus should have equal billing along with architecture, security, support, testing, etc. (Yeah, we’ve all experienced projects were testing is slashed, security is ignored, support is non-existant all to save money – that’s a whole other blog post in and of itself…)
- Please stop measuring the value of a project with a massive weighting on its overall cost – success must and should be measured based on cost and benefit together, and I guarantee up-front and continued focus on UX aspects will improve the project no end. It might actually reduce the timeline, the resources needed and the on-going support required – oh wow look, a cost saving driven by a benefit. Woot.
- If you can’t see how a quality UX approach could be a benefit, engage with someone who can help you understand this and ensure it is built into your success criteria for any future projects.
If you’re a consultant/consultancy:
- Think about how you could embed a designer and/or UX consultant into your project methodology.
- Educate your entire team about what UX is and what it really means.
- Build a watertight resource and cost model that allows your non-directly billable resource to contribute indirectly to the success of your projects, whilst retaining a viable model to keep your customers happy and still pay all of your bills and wages. Profit and success will quickly follow.
- Provide an environment where your designers and developers can co-habit and contribute together, that fosters an atmosphere of teamwork and sharing ideas. Get your customers into that environment too.
- Please see point 5 above 🙂
UX & design applies to every aspect of any solution you are building and has different meanings and requirements to all stakeholders. Get it right and everyone is a winner.
Excellent Gareth, I think you've hit the nail on the head here.
There is heaps of value to be had from investing in good UX, lower support costs, lower training costs, improved data quality, increased productivity and all leading to happier staff, happier customers and ultimately (at least from the bean counters perspective) a more healthy bottom line and increased profits.
Step 1: Sell the value of good UX and demonstrate the risk of ignoring it
Step 2: Get on with it and deliver it !
Thanks,
Simon
Thanks Simon.
I feel a lot of it is stating the obvious and yet we still don't see any sensible ratio of designer to developer in companies. I didn't make last night's Mentor call however some of the stat's coming out of SAP and collected from customer's suggest the problem is as widespread as we all fear.
I feel I can be a bit more preachy about it now too, as my current employer hired a UX Consultant not long before me and hence we have the dedicated resource in our office. I've only been engaged with him for a few weeks now and already I'm feeling and seeing the benefit across our internal and external endeavours. I find myself wondering "why haven't we done this before?" with even more conviction now!
Cheers,
G.
Thanks Gareth... I feel your frustration and I agree.
What's been resonating with me for a while now is the idea of Puzzles (solve for/solve by myself) vs Mysteries (solve with/no one person has the answer) mindsets.
Too often UX is treated like a jigsaw... hand over the pieces (your requirements) and I'll do it for you. Clearly there is only one right answer - tell me what answer you want and I'll build it. If we get it wrong.. shame on you for not providing all the puzzle pieces (your requirements list). And that's the mindset that thinks all we need is a developer... we will be told the design or we will pick the design from our off-the-shelf set of "best practices". Because that's worked so well before... not.
Really UX is more like crime-solving... everyone has a different perspective so you need to gather lots of opinions to get a whole picture; you need to see the scene of the crime to really understand it; you need to reach the 1st hand witnesses, and once you come to a solution you need to agree how to act (charge someone? let them off with a warning? put them on a good behaviour bond?)
To me, treating UX as a puzzle is what is at the heart of the reluctance to factor design and development resources and costs together on UX projects. Approaching UX as a mystery makes it obvious that both designers and developers need to be involved. I need the detective (the designer) as much as the forensic pathologist (the developer) to get to the right solution. I can't just point the forensic pathologist at the first blood stain I see and say "tell me who the murderer is" and have any hope of getting a good result. I'll just be called into the Appeal Courts (reworking the UI) again and again.
And both designer and developer need to be not only on the UX project but working in direct collaboration with each other as well as with the business, end users and stakeholders. Because while the designer brings the empathy and the collaboration and coordination skills, the developer brings the knowledge of what's possible and the effort/cost, so cheap low-fidelity prototypes can be quickly whittled down by cost/benefit alongside other intangible considerations.
Once you've agreed on the answer to the UX mystery... building the UI itself becomes a puzzle. Those who keep treating mysteries as if they were puzzles are doomed to confusion and disappointment, and a whole lot of wasted resources, financial and otherwise.
Elementary my dear Jocelyn!
What user researchers can learn from Sherlock Holmes
Great analogy to use when trying to explain the problem.
🙂
Lovely - I will add this to our next planned eLearning on User Research as further reading!
Thanks for your in-depth thoughts Jocelyn.
I'm loving the puzzle vs. mystery analogy you have described here and think it hits the nail on the head. I especially like your last paragraph, which I think succinctly summarises the situation. It is very easy to get lost in the lower level puzzles without really understanding what the overall mystery is.
In this perspective, I'm being greatly educated by my new UX consultant colleague and loving the challenges and differnt perspectives he is bringing to our solution designs and reviews.
I'll go further and say that UX focus isn't a magic bullet all on its own, and can also benefit greatly from other "different" approaches to what we are used to in the good old world of SAP. Agile practices of varying flavours for instance complement UX practices very well.
Ultimately, like so many improvements they generally work well if you put effort in and do them properly, rather than pretending to. Especially key to this is the point you raise about various stakeholders, and how so many different people can actually help shape and influence the quality of the finished product.
Cheers,
G.
Thanks Gareth... ! Glad it resonates.
Btw on reflection I think perhaps the forensic pathologist is a subject matter expert, and perhaps it's the lawyers who prosecute who are the developers... because even once we get to what we consider to be the answer (who done it) we still need to decide how we act upon that information... (let them off with a warning, community service, charge them with 1st/2nd/3rd degree). And really it's the actions we take together in the end make the difference.
But yes I agree absolutely with "putting the effort in" - it's not enough to pay lip service to UX and just do UI. You have to change the mindset not just the skillset.
Very true. I lead a lot of DT projects, and have come to the conclusion over time that a team building exercise on who does what and what artifacts are to be produced along a typical project by whom and how everyone has a part in the overall solution "design" is key to creating delightful solutions.
As part of the Global UX team, Sam Yen has asked me to create an eLearning ( or MOOC) course around just this topic in collaboration with UCSD.
You can find the self paced version here. We are converting the Beta course now to GA, so if you want to participate in the next version of the course, ping me!