Skip to Content
Author's profile photo Ramanathan Ganapathy

User Experience – Confessions of a SAPaholic

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 )

Factors - U, T, M, F.png

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.”

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Karthikeyan P B
      Karthikeyan P B

      Good one, Ram. I agree Technology and Design have to converge to offer the envisioned Experience to the User.

      Author's profile photo Former Member
      Former Member

      I agree with the concern but I disagree that all engineers will have  designer´s skill. At All time the SAP´s engineers and developers were conditioned to write code and not always think about a good experience by UX design or business rules. We have a big break of paradigm all of us. I think tha we need to discuss more about SAP´s UX  at community.

      Author's profile photo Ramanathan Ganapathy
      Ramanathan Ganapathy
      Blog Post Author

      Thank you, Alex Marin Silva, for your comments! I used to think the same: Design skills / creativity etc are the stuff of certain gifted individuals. Here, I am just trying to challenge this view. More views/counter suggestions are welcome!

      Author's profile photo Former Member
      Former Member

      First of all a Big Hello from an ex-colleague 🙂

      Nice one Ram. The last line sums it all up...

      • It isn't easy to please everyone when it comes to UI design so take critisism with a pintch of salt
      • Users cannot specify what they want when it comes to UI

      I think the best UI designs are a result of an iterative process which needs time which more often than not, is a luxury!

      Author's profile photo Former Member
      Former Member

      I am a web Developer and I do not see any reason why I need to become a voracious Designer. Well, all that matters to be is we need to have a common ground to liaise. I need to learn some design skills and so do I expect my designer to digest code.

      1. "Why we never bothered about UI?" - Well you summed up by using the word "bothered". Maybe we were busy fighting to possess the title of a "backend gladiator". UI has always been relegated and that's why we were never able to build pleasing one. They say that a good UI is like a joke, if one needs to explain it, then it's not good enough. We always have been EXPLAINED about what a good UI is all about. For the time being we should note that a good UI comes at a price.

      2. Designers vs Engineers - Some gentleman said that engineers are always CONDITIONED to write code and not to digress into design. How do you expect one to digress? If we talk about REST and HTML5, they talk about Typography, Kerning etc. Recently Google adjusted its logo which was a 1px kerning to the letter 'L' and how many of us ENGINEERS noticed that? Twitter moved from Helvetica to Gotham font family. If you feel that design is bestowed upon a golden few, then what would writing code? Smart chaps like the ones who built CSS frameworks like Foundation and Bootstrap comment that designers SHOULD code. And it's apparent, that it's going well. Chk out this article I think now we engineers, need to make moves to explore the Design arena.

      3. Chasm between the two - There WILL exist a chasm between the two working groups. The only way we could bridge this gap is fostering novel technology. A designer might provide with a exorbitantly flamboyant design, but if we engineers are EQUIPPED with the right set of tools and knowledge, then MAYBE we could pacify the other group. For e.g. these days, a very (over)hyped UI design is "Parallax". Truly a designer could provide a jaw dropping design and maybe the developer could built it. But the relation between both the groups will be strengthened if each one explains the strengths/pitfalls of such a design. Parallax suffers from terrible performance impediments if not implemented correctly. Do we ENGINEERS stick to the 60fps "thumb rule"? Do we use Chrome dev tools, activating the TIMELINE tab and studying the same in the frames sub-section? Do we perform JavaScript profiling? If not, then maybe ENGINEERS need to ENGINEER better before delving into design.

      I am very much comfortable being a web developer. I have average design skills (which I would like to enhance) but my focus would be to bring the best out of my designer and me together for the success of the product.