Usability first - from the frontend to the backend

How the user experience influences software development

In the era of smartphones and virtually unlimited technical possibilities, usability is key. Tom Sprenger, Group CTO, and Peter Boon, CTO AdNovum Hungary, talk about how this shift has influenced software engineering.

Compared with 10 years ago, how has software engineering changed?

TS: Our main goal is, and has always been, to satisfy the users’ needs. When we started building software, our customers’ processes were still paper-based. The main challenge was to build software to model these processes. This has changed dramatically. With the amount and availability of digital data growing at an astonishing pace, new possibilities and new needs have emerged. Today, we no longer take current processes as a given, but start by analyzing the business needs from the user’s perspective. This has had considerable impact on the way we build software, look at staffing, or handle tooling and technologies.


PB: The focus has shifted from the backend to the frontend. While we quite reliably master the backend applications, we — from project managers to developers — have to change the way we think and approach tasks on the usability side. New approaches are required. Previously, engineers could just do what they thought made sense. Now they have to take the usability aspects much more into account and maybe even discuss possible solutions with a usability expert. What a developer might consider to be a detail may actually be quite important. 

What a developer might consider to be a detail may actually be quite important. 

There’s obviously a paradigm shift taking place …


TS: Yes, this shift has considerable impact on the way in which we build applications. We now start at the frontend and work our way to the backend. The different layers of our reference architecture are decoupled. This allows backend engineers to focus on developing services and the frontend engineers to focus on implementing functionality from the user’s perspective — and hence to focus on user interaction. I’m convinced that we will benefit from this approach in many ways, one of them being that it increases the testability and flexibility of our solutions.


PB: It is easier for the younger engineers. They have grown up with much more exposure to applications with a "rich" user interface (UI) and mobile devices. To be able to reproduce and work with that is really cool for them, whereas more experienced engineers are used to focusing on functionality and the backend. Yet, whenever you get in touch with frontend, you have to just be aware that the UI is much more important than it was five years ago.

When did you first become aware of this shift in perspective?

PB: Working on a mobile banking project. We had a design company and it was all about creating a consistent UI for the whole app. There I realized that user experience (UX) is a big thing. As regards my first private UX experience, I’ve used computers for a long time. That grew naturally, starting with when mobile phones really took a flight.

TS: To me, it happened way back when getting in contact with the first Apple Macintosh around 1985. It was the first computer which came with a mouse that allowed drawing and cutting stuff in a painting application! Another UI revolution was the iPhone — the first mobile device to be designed around the user. At that time, established brands had big issues just to provide the functionality of mobile telephony and the user interfaces were horrible. Apple’s entry into the market was not so much based on functionality, but on providing a nice and innovative user interface. These two experiences made me aware of the added value of well-thought user interaction design. Looking back today, I think that its impact proved even more important than I had thought at the time Apple for sure is a special case, but it illustrates very nicely that the combination of being rock solid in the backend and very user centric in the frontend could be a differentiating factor on the market. 

How would you describe today’s typical app and software user?

PB: A few years ago, people could not imagine the systems which we were building. They would go from manual processes to an automated system. So whatever we would provide was great. It was about functionality. Nowadays, they are used to working with all kinds of websites and apps with high usability — and expect the same from us. They even give precise feedback about the solution, saying, for example, that the buttons are not placed correctly or something is inconsistent.

TS: In the earlier days, we mainly built applications which were used by our customers’ staff in their daily work, that is to say business to business applications (B2B). Today, we build business applications which are used by our customers to interact with their customers, namely business to business to customer applications (B2B2C) whose expectations regarding usability are even higher. But also for applications used within the enterprise, expectations have changed. In general, the end users’ benefit and experience take top priority today for companies, something which we realize again and again, for example, when working on tenders. To integrate the user perspective into the design process from the very beginning, AdNovum has established a dedicated UX team.

The engineers see having UX designers as a complementary discipline in the project
as a benefit. 

How does involving designers in the engineering process impact the work of developers?

PB: Dealing with UX designers is new, but not much different from a developer having to work with a business analyst. Of course, we had to adjust our tooling and processes to ensure seamless integration of the new tools and roles. 


TS: The early involvement of the UX team fundamentally influences the way how project teams talk about the solution which they are building. Non-technical topics gain importance. Developers see it as enrichment and acknowledge the benefit of having UX designers as a complementary discipline in the project.  

How do you make them speak the same language?

TS: On a roles and functions level, we see that, while engineers and UX designers are perfectly capable of understanding each other, there is a profile missing in between, namely the frontend developers. Frontend developers with their flair for user interfaces and a profound technical understanding act like interpreters between our engineers and the UX designers. As a result, it was evident that we had to hire additional frontend developers. On a technical level, we adjusted the software engineering process, different aspects of the software architecture and aligned the frontend tooling to reflect and support their involvement. 

Something which is easy to use may be quite complex to implement. 

Where does the customer fit in?

TS: As a well-established approach, we involve customers at a very early stage in a project. Our project platform provides the required tooling, such as collaborative services which enable the customer to see what we’re doing, from the early drafts to the first UI prototypes and the development. A good example is a project which we did for a logistics company. UX designers accompanied drivers on their trucks to see exactly what they were doing. Based on this, they presented an early prototype to the customer. Today, user experience is very important to gain customer acceptance, whereas a few years ago, the customer primarily expected the application to provide the required functionality.

PB: This is exactly why we positioned AdNovum’s UX designers very close to the business analysts. Together with the customer, they figure out on a functional level what the application should do and how it should work.  

If customers and users are involved from the very beginning and help engineer the best solution, where is the challenge?

TS: The major challenges are that, to begin with, something which is easy to use may be quite complex to implement, and then that, to do so, you have to choose between endless UX possibilities. In close cooperation with the customer, we have to find the most suitable solution, set the right priorities, pick the right hot spots and define a roadmap for the solution to evolve. From a technical point of view, a major challenge is to provide applications without any media disruption, from UX to frontend to backend.

PB: Quite a lot of effort and time goes into details and making them work. When the business analyst and the UX designer figure out at an early stage how a solution should work, they choose the general screen layout and flow. But then a number of details need to be defined such as how do different controls have to work? How about responsibilities, response times, speed, accessibility, user navigation with keyboard and shortcuts? These things might change during the process and the time required to implement them is easily underestimated.

Do you have to re-design your applications from scratch to make them user-friendly and stay competitive?

TS: No, the core can quite often be reused. The almost revolution takes place on the UX level where we see substantial development and motion. Often, legacy applications are cut on a suitable tier and a new frontend is popped onto them. In many cases, the only real change is how functionality is presented and how users interact with it.

PB: In addition, multiple frontends — for example a mobile app, a desktop application or a website — can be used to access the same backend. 

The almost revolution takes place
on the UX level. 

What if a customer asks for the impossible?

TS: Then, he’s at the right place with us! (laughing) Since we talk to the customer at a very early stage, it’s all about expectation management. Of course, there are limits, but we try to push those limits hard. 


PB: Users have certain expectations based on what they have seen in other applications. However, they also know the limits. An example: we are currently re-implementing a desktop application into a web application. The users understand that we cannot provide the same functionality at 100% because the web application needs to run in a browser.


TS: Most applications run on a certain system which already has some UX guidelines, for example how to swipe, delete or implement a list. However, on rare occasions, customers do come up with unusual ideas, for example an application where a certain element is scalable in multiple dimensions and has a really complex visual functionality. Although this is technically possible, we do not recommend implementation of such requirements because it does not comply with the specific guidelines of the operating system (OS) and hence, this would have a negative effect on overall user experience.  

How do customers react if you advise against a requirement or functionality?

PB: Generally, they understand the reasons and they accept it. For example, when we migrate a desktop application to a web application, they usually understand that there are limitations. Or if the customer’s requirements are in conflict with the policies of an app store, we can only suggest and provide alternatives.

From a user-experience point of view, how does a browserbased solution fare when compared with a fat client?

PB: People have become used to browser technology because they use online services. Yet, compared with a fat client, there is always a little delay. However, we can overcome this gap quite well and it is not a "no go" for web applications.


TS: There has been major progress in executing web applications in a browser. All the big companies, including Oracle, Apple, Mozilla and Google, put tons of effort into improving the execution speed of web applications, from which also usability greatly benefits. 

Big companies put tons of effort into improving the execution speed of web applications, from which also usability greatly benefits. 

How does this affect the technologies which are used?

TS: Technology cycles keep getting shorter. What is cuttingedge today may be outdated tomorrow.

PB: Some 10 years ago, we replaced many legacy applications for exactly this reason. As for the generation for which we are now building, I am not sure if the replacement cycle will accelerate.

TS: I would rather expect a flat curve on a high level. Currently, mobile is still a hot topic, as everybody has his/her own ideas what to do with a mobile device. Another one is mobile payment. 


PB: For enterprise applications, the technology cycle is less of an issue. But those end-user-facing applications are really a different category. At the time when e-banking applications were going mobile, I saw cases where just the UI was upgraded in several iterations to stay competitive, without any functional changes. 

Given these shrinking development cycles, how can you ensure efficient technology management?

PB: AdNovum has always had a very good and strict technology management process. This has become even more important with the number of components, frameworks and third-party libraries increasing dramatically over the last two or three years. Basically, we rely on our experience and prefer tools which have been tried and tested. Once we have decided, we focus on the selected tools, invest in their integration and build up know-how. In case of open source components, we also take into account the community which is behind them, how long it has been around and how many people are contributing. Based on these factors, we can make quite reliable predictions about whether a tool will continue to provide the features which we are going to need over the coming years. 


TS: Currently, we are building our frontend technology stack as a managed stack from where we can start when developing a customer solution. Unlike for the backend, there are hardly any standards for frontend tools besides the core technologies, such as HTML, JavaScript, and CSS. On top of this, there is no standard widget set, for example. The fragmentation is also much higher, i.e. the libraries are much smaller — just snippets in some cases. The challenge is to pick the right ones and make sure that they integrate nicely so that we can efficiently build user-centric and reliable solutions for our customers.



Tom Sprenger
Tom Sprenger, Dr. sc. techn. from the Swiss Federal Institute of Technology (ETH), joined AdNovum in 2000 as a Software Engineer. From 2002 to 2004, he was Head of AdNovum Software Inc. in San Mateo, CA. In 2007, he was promoted to Chief Information Officer (CIO) and a member of management. In this function, he built up the strategic business area IT Consulting. Since 2013 he has assumed responsibility for the company’s technology strategy and engineering process in his role as Chief Technology Officer (CTO). In his private life, Tom Sprenger enjoys spending time with his family and going on a downhill bike tour every now and then.

Peter Boon
Peter Boon, MSc in Computer Science from VU University Amsterdam, started working for AdNovum Hungary in 2009 after moving to Budapest from The Netherlands. He had the technical lead in various desktop and mobile related projects. As CTO AdNovum Hungary, Peter Boon took part in defining AdNovum’s strategy for mobile applications. Outside of work, he enjoys running, photography and travelling with his family.