Make it Work, Make it Right, Make it Fast – Adapting to UXaaS priorities
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:
- Make it work
- Make it right
- Make it fast
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”.
So what is UXaaS?
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|
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?
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?
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?
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.
Adapting to UXaaS priorities
If you are a developer in UX projects:
- Align your definition of “Make it work” to User Experience
- Respect the value of the Discover and Design phases
- Consider if you have the aptitude and desire to add design skills to your development skills
If you are a solution architect with UX responsibilities:
- Align your definition of “Make it work” to User Experience
- Understand that Discover and Design phases uncover criticality, importance and relevance points you need to understand to organize the solution and make effective trade-offs
- Consider if you have the aptitude and desire to add discover skills to your architect skills
If you are a UX designer:
- Understand that developers and solution architects need more than just a prototype and a requirements document – they need to understand the thinking behind it so they can make effective technical and architectural decisions
If you are a design thinker involved in UX discovery:
- Understand that developers and solution architects need more than just the summarized bullet points from the workshop
- Include carefully selected developers and architects in the discover phase – aptitude and mindset for UX are critical in choosing the right people
If you are a manager:
- Consider the mindsets and aptitude of your people when placing them in Discover, Design, Develop and Deploy phases
- Developers who are creative & collaborative are typically those who best pick up design skills
- Architects who are collaborative and have a UX “Make it work” mindset may be suited to picking up discover skills
- Those with deeply ingrained play-it-by-the-book or just-following-orders mentalities will find discover and design difficult and are better in develop and deploy
- Understand that new skillsets are required for discovery and design. If you don’t have access to designers you may need to position some of your people to grow into those roles
- Consider the resources you will need to skill up your people
- SAP is providing some additional tools to help you scale UXaaS
- The new Splash and BUILD tools are aimed at helping people with aptitude to pick up new skills in discovery and design respectively
- Design Thinking with SAP https://designthinkingwithsap.com/ provides support and services for the Discover phase
- SAP’s User Experience community at https://experience.sap.com/ also has considerable design resources
For a deeper discussion on skilling up for the Discover and Design phases respectively, you’ll find my subsequent blogs here: