I never thought I will write a blog about UX – though my work at SAP has been revolving around various UI Technologies. This might double as a confession, as much as my thoughts and experiences on UX Design and Technology. I didn’t hate UX as such, but I reasoned, that’s the stuff for lesser engineers. Until, I picked up this book in the SAP labs Library – the strangely titled book : “Notes on the Synthesis of Form” by Christopher Alexander. Written 50 years ago, this was the first attempt by anyone, to define the design process: “the process of inventing things which display new physical order, organization, form, in response to function..." This book, I figured later, is a classic and though its focus was mainly on Civil and Mechanical Engineering, it has influenced many thinkers, creators in the Computer Science field and resulted in paradigm shifts like Design Patterns, Design Thinking, even, Object oriented programming.
Being put in my place, at the end of reading this book, I started to fill out the spaces in the “engineer” in me. I tried to answer this question: why I never bothered about user experience of solutions I built ? I reckoned: We, the engineers, “build” software. The users “use”. We “think”, they “feel”. And I wondered, how can a bunch of UX designers in my team, suddenly make the products “we” build, to be more “use”ful ? To be fair to them, they always try to help me. But then, most of them get lost in translation.
The Designers talk about User Interface, User Centric Design, UI Design, User Experience etc.
The Engineers know UI Technologies, UI Frameworks, UI Tools and Clients, Platforms etc.
And to add to the mix, there are influencing factors like Customer/End User expectations, Functional Scope of what we build and the Methodology we use.
The engineer and the designer live in different worlds and talk different languages. Time to come together.
The Big Question: UX – a means to an end ? Or an End in itself ?
I see the dynamics between the actors: UIDesign, Technology, Functionality and Methodology as follows:
Product Outcome = function ( U, T, F , M )

Individually, each of these actors are significant. More so, when they influence each other. For example, the advent of RESTful architecture, resulted in new paradigms in UI design. Innovations like HTML5 has pushed the limits of imagination of UI Designers. Conversely, UI Design has also been constrained by the Technology feasibility and we have struggled to work-around this problem. For instance, browser based applications have had sometimes, awful usability, due to limitations on navigation (browser “back” button vs Application “back” button) and speed (well, you know, we blame the network). There are some positive influences too: for example, with HANA, the “Data on Top” principle means, we provide APIs as per User Interface Design requirements and not the other way around.
It gets tricky when we see all these 4 come together: In Waterfall methodology (M), a significant amount of the functional (F) scope discussions revolve around UI Design (U). But how much can we “freeze” the UI Design as part of specification process? What if, while during design, we find the ideas not feasible (T) ? There are no simple answers. And working on only one of these factors – say, changing the Methodology, for instance, to Agile / SCRUM etc, is not going to eliminate all the problems. Sometimes, out-of-the-box thinking is required: In one of my projects we added an additional project milestone called “Delivery of UI Screens” worked. This was not just plain mockups, but the fully working UI solution without any business logic, delivered sometime between Specification and final Development closure. It kind of helped the team, focus on Technical Design based on UI expectations and Functional requirements, but freeze the UI part, receiving a sign-off, before building the full-blown software. Early feedback and closure, in a Waterfall method is always a blessing!
I only examined 4 factors influencing the product outcome. There might be more. We will learn. However, more specialization (more Quality Engineers, more UX Designers etc) may not be the key to solve engineering delivery challenges like scalability and speed. In my humble opinion, Every engineer should have a designer in him/her self.
I leave you with the quote from another classic: “Are your lights on ?”
“In spite of appearances, people seldom know what they want until you give what they ask for.”