Image courtesy of suphakit73 at freedigitalphotos.net


Learn skills you need to work in the Design phase of UXaaS and where SAP BUILD – the prototyping and user research tool under the SAP Splash umbrella site – fits.  This blog is aimed at developers and architects looking to pick up some User Experience design skills – and gain new perspectives on what we mean by “Make it work”.

ID-100102538.jpg

Recently I have been posting some blogs on adapting to UXaaS priorities:

Make it Work, Make it Right, Make it Fast – Adapting to UXaaS priorities

Make sure it Matters – Skilling up for UXaaS Discover phase with SAP Splash

Of all the UXaaS phases – Discover, Design, Develop, and Deploy – I view Design as the most critical of all to UXaaS success.

One of the big mistakes I have seen a lot of IT people make is to think design is primarily about aesthetics.  It is not.  It really isn’t.  Yes there are some aesthetics but that’s a comparatively small part of what designers do.

Design is primarily about Making it Work

In the Design phase we synthesize the data and points of view insights we gathered in the Discover phase and transform that into a deeply pragmatic, touch-and-feel prototype that makes user experience work primarily for end users, but also for stakeholders and business.

When done right, the Design phase is the most effective way to minimize costs in the Develop phase and to drastically reduce change management and support costs in the Deploy phase.

What Make it Work really means

Fortunately many are increasingly grasping the difference between how IT traditionally interprets “Make it work” and how end users, business and stakeholders interprets “Make it work”.

A conversation with a friend at the recent Sydney Developer and Architect summit reminded me of the difference. 

When IT people talk about “Make it work” they usually mean something like:

If you fill in the fields correctly and press the appropriate button, the user interface makes the correct request, the request traverses through the appropriate integration layers to the relevant system, the system performs the desired activities, gives the appropriate response, and the response is successfully returned and presented to the user interface.  It works as expected.

Over my own UX journey I’ve had to downgrade a lot of my own “Make it work” explanations to no more than “Make it possible”, i.e. the technology works as expected. But that’s not at all what I mean these days when I say “Make it work”.

Let me give you an example of the difference between “Make it possible” and “Make it work”.

A week ago I was singing Gloria by Rutter as part of my local choral society.  It’s a complicated but very satisfying piece. Here’s a Youtube video showing another choir doing it well: Gloria by John Rutter

There are many elements that need to come together to make this possible:

  • The composer had to write the music down in a manuscript that others could follow
  • The choir committee needs to hire enough copies of the music for the conductor, the musicians and the choir
  • The conductor needs to learn the music
  • The choir needs to learn the music, integrate together, and watch the conductor
  • The musicians had to learn the music, integrate together, and watch the conductor
  • The conductor needs to coordinate the choir and the musicians in following the manuscript
  • Depending on the concert setting & whether it is being recorded we may also need specialist audio, video, lighting people & equipment
  • The audience needs somewhere to sit
  • And we need people to promote the concert and sell tickets

Here’s what end users, business people, and stakeholders mean by “Make it Work”:

  • Everything came together to make a great sound and a wonderful concert

Unfortunately all too often the traditional IT interpretation of “Make it Work” tends to sound something like this in the ears of end users, business people, and stakeholders:

  • I gave you the manuscripts
  • I gave you the instruments
  • I booked the concert venue
  • I put the concert advertisement on the choir website
  • I set up the chairs
  • I turned on the lights and the sound
  • I made it all possible

…it’s not my fault if you don’t know how to make music together!

And of course at this point end users area saying “But some of the manuscripts are illegible, some have pages missing, and the light’s in the wrong place so some of us can’t see them”, and the business are saying “there’s hardly any parking at the concert venue, the venue is too small, the sound is fuzzy, customers are complaining that the credit card payment is too slow”, and stakeholders are saying “what happened to my concert?”.

That’s maybe a little harsh because I’ve met many developers and architects who at least try to understand and assist as best they can. Too often by the time these problems are revealed it is already in the Deploy phase where fixes are difficult and expensive. 


I find it instructive to compare and contrast the developer and designer viewpoints of “Make it Work”.

Look at this excellent blog by developer Eric Elliot where he uses the “Make it Work” principle to advocate for simplicity in JavaScript coding:

The single biggest mistake programmers make every day

Then at this blog by Navdeep Ganesh a professional designer in our Design and Co-innovation Center on what makes a good user experience work:

What makes a good User Experience

And finally at this short blog which makes the “Make it Work” interpretation differences all too clear:

End Users and IT disagree on definition of good desktop user experience

There is a definite difference of opinion in the understanding about what’s involved in “Make it Work” and who is responsible for achieving desired business outcomes.  Especially when we get to the Deploy phase where if things aren’t working the relationship between IT and business becomes decidedly acrimonious.

Someone needs to bring it all together for a more complete understanding of what it will really take to make it work as early as possible so that:

  • Clear responsibilities can be assigned for the Develop and Deploy phase
  • Integration points – human/human, human/system, system/system – are identified and can then be managed properly

In UXaaS, that person is the designer.

What designers actually do

Designers synthesize the data and points of view insights gained in the Discover phase with the needs of: end users, stakeholders, business people, and IT.

I was privileged to be introduced to Navdeep Ganesh by long time friend and colleague David Ramsay at the Palo Alto DCC just before Teched 2014.  Just talking to Navdeep & his colleagues about how they approached design and watching a little of what they were doing opened my eyes tremendously to the depth of discipline in design.  In my opinion, the design discipline is just as deep and as scientifically rigorous as anything we deal with in development.

I’m also indebted to Navdeep for introducing me to a range of usability terms that as a developer with – at that time – somewhat limited design skills has led me into a much deeper understanding of design. Especially the “baby duck syndrome” – as listed in this blog on Usability Issues to be aware of – one which I’ve seen happen again and again and again over my career in IT… and is just one of the barriers to overcome in achieving good UX.

When it comes to consumer design, most of us would very strongly recommend getting the services of a professional designer, such as Navdeep & his colleagues.

Professional designers perform a wide range of activities.  Designers attempt to understand how the end user thinks about the task at hand and the context they are in, and then turn that into a user experience that is intuitive, engaging (so the user is motivated to complete it) and effective for both the end users and the business itself.

Just as developers and architects subclass their specialities – such as Web Developers, ABAP Developers, Security Architects, Enterprise Architects – designers also have specialities – such as Visual Design, Interaction Design, Communication Design.   Designers even need some psychology skills to understand how to work with users and interpret an end user’s non-verbal signs of pleasure, distress, or confusion with the user’s experiences.

However a lot of the UXaaS journey is internal to the organization and with so few designers available, developers with a good UX mindset, some aptitude for design, and who are prepared to pick up some design skills can be extremely helpful in filling the design resources gap.

What needs to happen in UXaaS Design phase

In the UXaaS Design phase the main activities we need to do as designers are:

  • Synthesize needs of the end user, business, stakeholders, and IT
  • Draw up low-fidelity (paper/pencil or whiteboard) prototypes with the users
  • Transform low-fidelity prototypes to high-fidelity (close to final look and feel) prototypes that fit with design principles and guidelines
  • Validate prototypes with users business, stakeholders, and IT to ensure:
    • Nothing has been forgotten
    • Nothing unnecessary has been added in


And especially when it comes to SAP UX, keeps the Fiori Design Principles top of mind to ensure UX is consistent and scalable regardless of task, device, or platform.

fiori principles.JPG

The Developer-turned-Designer advantage

One of the areas of UXaaS Design where there’s actually an advantage in having development skills is making sure the high fidelity design is possible. There’s no point in creating fantastical designs that can never be implemented in practice.

That said, a sure sign of a developer who does NOT have the right mindset or aptitude for design is someone who tries to limit the design to what-I-know or what-we-do-now or even the narrow confines of the heavily abused term best-practice.

Not to get too snippy about a lifetime of experience in IT: but in my opinion, best practice would be better termed as best default practice.  If you struggle to understand when best practice fits and when it needs to be put aside so that real business outcomes can be achieved, perhaps you aren’t quite ready for the UX Design phase.

Skilling up for the Design Phase

Professional designers use a range of tools and techniques that match their specialization. One of the most common is Axure.  If you are working with professional designers, SAP provides stencils and tutorials to assist with creating prototypes based on Fiori design principles and controls.

But for most of us, we may not have the time, energy or budget to become full time professional designers so we need something a little easier – and that’s where SAP Splash and in particular SAP BUILD fits in.

Once again design thinking and design thinking techniques are useful especially for bringing end users, stakeholders, business and IT towards a common understanding of needs and possible solutions. You can find these in the Splash Learning Center.

A good way to start UX design is to take the Discover phase data and points of view into a design thinking workshop with end users, business, stakeholders, and carefully selected IT folk to generate some ideas and whiteboard some prototypes together.

Note the “carefully selected IT folk” – whoever you bring in is there to LISTEN and understand.  Towards the end of prototyping their role is to help indicate if something in the prototype is definitely possible, requires investigation, could be tricky or might be handled in a better way.  What they must NOT do is control or lead the design – especially they are NOT there to restrict the design to “what we’ve always done” or push the design towards “the new shiny tech I want to play with”. They are also there to help socialize the implications of the design with others in IT – e.g. if the prototype involves tablets, they should let whoever is responsible for the BYOD policy know.

SAP BUILD is a prototyping tool aimed at – in Sam Yen’s words – “the citizen developer”, who wants to get involved in UX Design.  It’s a deliberately simple tool enabling you to:

  • Quickly put together low-fidelity prototypes from screenshots of paper/pencil or whiteboard designs with simple hotspots for navigation
  • Publish prototypes so that users can try them out for themselves, and to socialize the design with stakeholders, business and IT
  • Create user research studies from your published prototypes – so you can ask end users to perform a task using the prototype with realistic mock data and get feedback – verbal (comment tags on the design itself) and non-verbal (emoticon happy/neutral/sad ratings, heatmap of click points) on whether the design really works for them
  • Create high fidelity prototypes using Fiori inspired controls and interaction behaviours
  • Run user research studies on high fidelity publish prototypes to make sure it still works for the end users, meets business needs, and to socialize the final design

As an extra bonus, SAP BUILD provides Web IDE integration so you can take your high fidelity prototype and turn it into an immediately executable Fiori app that your developers can understand and refine.

SAP Splash further helps by providing a Gallery of high quality sample designs that you can clone into BUILD to kickstart your prototyping.

Make sure you are being honest with yourself about how much of a designer you want to be. Sure there’s a lot of skills and knowledge you can pick up along the way:

But there’s always a point at which you may need to say “Ok! we need a professional designer’s help here”.

Why you should get involved in the Design phase

The Deploy phase, and even the Develop phase are both way too late to figure out why something isn’t working.  That’s one of the reasons why the cost of fixing problems in these phases is so high.

UXaaS development lifecycle.JPG

You see when end users, business people and stakeholders say “Make it work” they are looking for a lot more than just make it possible. Make it work for them includes:

  • I can find the app and launch it successfully
  • I understand what task I am performing and what I need to do at each step
  • The words and terminology make sense to me… I don’t have to look up another document or help site to find out what to do next
  • It understands the context I am working in
    • If I have to work with a lot of distractions it doesn’t force me to remember lots of things
    • If I am out in the field it works on the device I have available
    • I shouldn’t have to stop in the middle of the app to go and get barcodes and cost codes and product numbers just to complete the task – or if that’s unavoidable I should be able to save wherever I am up to and restart again from where I left it

If you have the:

  • Right mindset – an end-user/business centric view of Make it Work
  • Right aptitude – creative, collaborative and solution focussed
  • and are prepared to pick up some design skills – whether you do that using SAP Splash/BUILD or some other tool(s)…

… we could really use your help in the UXaaS Design phase.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Sana Salam

    Very nice article. Lots of good information.

    However, I must make one correction that Axure is not  meant for professional designers. Once we upload the Fiori icons/controls libraries into Axure, It can be used by business users.

    We found the usability of Axure for Fiori apps to be far more powerful than any other tool.

    We use Axure for building business case for Fiori, creating roadmap and creating lots of prototypes very quickly (less than 5 minutes per app).  The customers are not ready to hire a developer or designer until they have a business case/roadmap.

    It is also much easier to modify an Axure based prototype on the fly (e.g. during an iterative feedback meeting).

    We also utilize Build for getting feedbacks on our paper prototypes, napkin pitches and sharing design thinking outputs. This is also a great way to collaborate with offsite users and share information.

    However, we found that it was a bit difficult to engage the users in feedbacks using a tool and we had to schedule meetings/send reminders to engage them for these feedbacks.

    (0) 
    1. Jocelyn Dart Post author

      That’s very interesting Sana! 

      Nice point about following up on user feedback…. yes you don’t want that feedback to go out as a cold call, they need to know it’s coming and some sort of timeframe for getting back.

      Re Axure as a business user tool… well that’s another perspective. When I visited the folk at DCC, Axure and Balsamiq were favourite tools.

      Forgive the cynicism of a long term IT person but every second tool is marketed as “can be used by business users” … and I’ve also seen this claim made of SAP BUILD. Previous experiences with those sorts of statements tends to suggest there’s quite a large gap between can and will

      We may find the occasional business person who will give it a go – especially with low-fi prototypes – but in my experience its unrealistic to expect them to pick up the depth of design and in some cases programming knowledge needed to produce high fidelity prototypes that are grounded in reality.

      My preference is to select tools where you would be happy for a business person to sit alongside you while you work and give immediate feedback – and I’d be happy to put both BUILD and Axure in that category.

      (0) 
      1. Sana Salam

        Very nice and I agree.

        When we do design thinking with customers, its a very planned activity. There are pre-planned tasks for business leads, project managers and designers where we co-create story boards, napkin pitches and low/fid wire prototypes. The entire workshop needs to finish along with lots of prototypes in 1 day.

        Many of these apps are for senior executives and the customers dont feel comfortable showing them low/fid mockups. They want to show something more presentable that could be touched and felt. Due to the divergent approach of prototyping, we use Axure for prototyping and utilize Build for sharing design thinking outputs.

        By the way, I personally know David Ramsay and Navdeep very well due to our experience in Design Thinking at SAP labs.

        I have not used Splash with a customer yet, at that time we couldn’t find all the controls and icons in it (Beta version). I am looking forward to working with Splash in future. It looks like an awesome tool specially because it integrates with WEBIDE.

        It is amazing how HCP is becoming such a great developer platform with all these additional tool integration with it. This is the true power of HCP where we can use it way beyond just a cloud deployment platform.

        (0) 
        1. Jocelyn Dart Post author

          Thanks Sana – again excellent suggestions!

          Just one point to clarify re Splash and BUILD … Splash is the umbrella site under which accelerators, learning, inspiration gallery, and tools such as BUILD are offered.

          That’s one of the things I talk about in the two previous blogs Make it Work, Make it Right, Make it Fast – Adapting to UXaaS priorities and  Make sure it Matters – Skilling up for UXaaS Discover phase with SAP Splash


          The new BUILD Beta 4 gets us a lot closer to building high fidelity Fiori protoypes as it provides a lot more of the SAPUI5 controls.

          You’ll also find details of the WEB IDE integration here. Kickstart your Fiori Web IDE project with Splash and BUILD

          (0) 
          1. Sana Salam

            Alright. 🙂

            We do plan to use Splash in our next design session.

            By the way, you are an excellent writer. I enjoyed  reading your blogs.

            (0) 

Leave a Reply