Consulting - is there a better way? or "Where are ...

Former Member · ‎2015 Aug 12

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.robinsonhas 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 :smile:

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.