Image courtesy of PinkBlue at freedigitalphotos.net
If you are a developer or solution architect you are already struggling with a vast amount of change – new programming languages, new methodologies, new security protocols, new devices, PaaS, IaaS, SaaS - and then you watch the SAP Teched Las Vegas replay Designing Digital Transformation: Scaling user experience in the enterprise and hear Sam Yen has added UXaaS.
User Experience is the latest CIO hot topic and you decide you need to get your head around this UXaaS thing. Successful UX can be confusing for someone coming from a traditional IT background – is it technology, is it platform, is it design, is it design thinking, is it prototyping/wireframes, or something else entirely? As a developer and architect myself, let me break down for you.
I have worked with nearly 80 organisations over many industries during my IT career and I find it fascinating how UX is changing IT practices for the better. But as a consultant who talks to lots of different customers, partners and independents all too often I see IT people struggling to wrap their minds around what really makes UX successful. Designers know but struggle to explain it to developers. Strategists give a high level view but struggle to communicate how UX impacts a solution architect.
Having been on this journey myself over the last 3 years I’ve tried lots of different ways of communicating the message. It’s not easy because for many it requires a fundamental shift in thinking. This week at the Sydney Developer and Architect Summit I had a bit of brain wave, and I tried out a new way of explaining UXaaS to a room full of IT people, and this explanation seems to cut through. So bear with me and maybe it will help you.
It all comes back to a well-established maxim about development priorities:
I find most people in IT are very comfortable with these priorities. After all, if it doesn’t work, I don’t really care if it’s built right or fast because it’s useless. Make it fast is about efficiency – we can interpret fast as performance and/or project speed. From a performance viewpoint, if it works and provided it’s fast enough, I’d rather make sure it’s supportable and adaptable – i.e. made right. And from a project speed viewpoint, if it makes it more reliable and robust, I want to take the time to do that to avoid high TCO.
Let me add one more priority up front:
Make sure it matters
Most IT people already understand make it right and make it fast, but to adapt to UXaaS you need to grasp “Make sure it matters” and you may need to fundamentally change your understanding of “Make it work”.
Firstly let’s deal with the name itself – UxaaS. If you watched Sam Yen’s strategy talk you already know this is a little different to PaaS, IaaS, and SaaS. We aren’t talking platforms, hosting, cloud and technology options with UXaaS… although we do have some tools in the Cloud, and some platforms that help.
PaaS, IaaS and SaaS enable us to scale platforms, infrastructure, and software services. UXaaS draws parallels to these in its approach to scaling User Experience renewal across teams and organisations.
Core to the UXaaS is the UX development lifecyle, which Sam describes as 4 iterative phases: Discover, Design, Develop, and Deploy.
As you can see from the Forrester Research (State of Customer Experience 2012), the early phases of Discover and Design are crucial to avoid expensive problem fixing later. A mistake in Discover costs $1, in Design $3, in Develop $30, and after development $75. Crucial to scaling UX is building resources with skills in discovery and design, as currently demand far outstrips supply in these skills, particularly design.
As a developer & architect I find it helpful to draw parallels between the UXaaS phases and development priorities.
UX Phase | Development Priorities | Critical considerations |
Discover | Make sure it matters | We have a lot of UX to renew and a big journey to take. Are our first targets apps that have real business impact? Are we picking targets that motivate end users, business and stakeholders for the next steps in our UX journey? |
Design | Make it work | Do we have a clear understanding and are we clearly communicating how this app will meet both end user expectations and business outcomes? Have we validated the design to make sure we haven’t missed anything critical? |
Develop | Make it right | Are we building apps in a way that is robust, reliable and supportable? Are we ensuring that critical design elements aren’t being eroded by trade-offs we make in development? |
Deploy | Make it fast | Are we using technology efficiently? Are we efficient in the way we use our resources? Are we thinking all the way through to how we distribute and support the new UX to minimize TCO? Are we making sure we are realizing the benefits we identified in the Discover phase? |
The crux of UXaaS and UX generally for IT people is coming to a new understanding of what we mean by “Make it work”. It’s not about features, functions, & flow. It’s not about devices, tools, and platforms. It’s not about aesthetics, or controls, or even Open Source. And it’s definitely not about methodologies, protocols, and best practice.
User experience is about whether the user interface technology fits readily to the end user. Great user experience makes it easy for the end user to complete the task correctly. Great user experience understands the user’s context – the situation in which they are performing the task. Great user experience supports users performing the same tasks but with differing skill levels. That’s what we now mean when we say “Make it work”.
It’s still important to build things right and fast. But the open secret of UXaaS is that Discover and Design it makes it easier for you to make it right and make it fast. If we do Discover and Design right we not only know exactly what we need to build, we know what’s important, we know what’s relevant and what’s not. And that helps IT excel at making effective decisions on all sorts of other behind the scenes trade-offs that developers and architects routinely make.
If you are a developer in UX projects:
If you are a solution architect with UX responsibilities:
If you are a UX designer:
If you are a design thinker involved in UX discovery:
If you are a manager:
For a deeper discussion on skilling up for the Discover and Design phases respectively, you'll find my subsequent blogs here:
Make sure it Matters - Skilling up for UXaaS Discover phase with SAP Splash
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.