Consistent UX in distributed product development

Enterprise software development is largely distributed. Solutions are built on a platform, but developed separately from it; the assembly of modules and their adaptation to customer requirements takes place downstream, in other locations. This means different teams, different departments, different companies are building something that is first a product for the customer.

Users expect software that is homogeneous , that reuses operating patterns, and that provides a consistent user experience. This is a major challenge when different departments, some of them distributed around the world, are involved and everyone participating in product development brings their own perspective to the table. As described in my previous article, a basic awareness of the topic of UX throughout the company is already a good prerequisite. How can we build on this and provide even more targeted support in terms of end-to-end UX?

UX influencing is key

Craig Villamor’s presentation “Resilient Enterprise Design” had a profound impact on my view of this challenge. Craig is a Design Director at Google and was previously responsible for the design of Salesforces software. In his presentation at the 2017 Enterprise UX Conference, he uses the four pillars of Design Principles, Platform Mindset, Design Systems, and Influencing in Product Development to show how successful UX design of resilient enterprise applications can succeed.

I would like to focus here on the last pillar, influencing. What is meant here is influencing all the players involved in product creation – at CONTACT, we call them “creators”. This support is also a central aspect of the UX strategy at CONTACT. But what does this look like in concrete terms?

Making it easy to do the right thing

It is not always a good idea to keep the design framework as large as possible: Too many design options can lead to uncontrolled growth and unnecessary inconsistencies. For example, fixed layouts for pages or control elements specify recognizable operating patterns. The manageable design options should then be explained as contextually as possible, in structures with which creators work directly – for example, right in the configuration interface. Such aids can be speaking titles and short descriptions for given layout areas, for example semantic sections in a context menu. In this way, creators can make the right decisions directly without having to go through the design documentation.

Support with the right resources

Good design documentation is also relevant: Design guidelines are the framework for design decisions in application development and configuration. It is important that they are not textbook-raised, but close to the creators’ problems. At best, the documentation for each UI component includes guidance on which use cases it is appropriate for – and which it is not. Examples show how the UI component is used correctly, for example in interaction with other UI elements.

Leading by example

Creators love examples in general: What can you do with this kit? What do possible solutions look like? CONTACT’s products offer an ever-growing number of specialized applications (Task Manager, Xbom Manager, Scheduler, Variant Management, etc.) that build on the InSync Design System and provide Creators with templates or inspiration for new solutions.

So if we provide distributed product stakeholders with guidance for design decisions, support with good application design resources and create lighthouse solutions for orientation, they can more easily create compelling products with a consistent user experience.

UX is everybody’s business

Professionally and privately computer work and the use of apps and other digital tools have become everyday occurrences. UX ensures the easiest possible operation and focuses on the user experience. This means that digital products are intuitive, reliable and, at best, fun.

Why is a UX strategy important?

The goal of UX is to make the interface between man and machine as comfortable as possible. This includes the “Look & Feel” of the respective tool. It is equally important that the user learns the operation as quickly as possible and can work efficiently. In order to achieve this, it helps to take the user more into account during the development process.

Particularly in the development of complex products, such as business software, many people are often involved in the development – and they all set different priorities. As a result, it is often difficult to control the user experience in the development process.

With the help of a UX strategy, the design of the user experience is given a direction. A focus is set so that product managers, concept developers and developers know what is important in terms of UX and where the journey should take them.

But what does such a UX strategy look like?

Strategy first means formulating a goal and developing an idea of what measures and means should be used to achieve that goal. Established frameworks can help. The UX Strategy Blueprint by UX veteran Jim Kalbach is such a help. We successfully used it in the CONTACT UX team to formulate a UX strategy for the company. In June, at the UXStrat Europe conference, I reported on our experience with this method and also spoke about it in the UXStrat podcast.

The strategy will trigger many innovations in favor of a better UX. For example, using a mockup tool for the first time and testing operating concepts long before the first line of code is written. That’s exhausting at first, but it’s worth it!

How do you live UX? And what does that have to do with me?

A UX strategy alone does not do much good – you have to live it. In addition, it makes sense to involve colleagues from development and product management as early as the strategy development process.

A good user experience is designed at every corner and end, from the platform building block to the form configuration in the customer project. However, UX specialists cannot be involved everywhere. We lead the way, define the strategy and provide support – everyone is called upon to implement it. For us, support means providing colleagues with the right tools, resources and examples. So everyone can independently contribute to a state-of-the-art UX and develop a positive user experience for the user.

And when the end result is powerful and user-friendly products, everyone benefits.

IoT failures and trust in technology

At the beginning of April this year I attended the building IoT in Cologne. At the conference, which was organized by heise developer, iX and d.punkt publishing house, everything revolved around applications for the Internet of Things (IoT) and Industry 4.0 in lectures and an exhibition. Together with my colleague Yang Zhong, I presented modern user experience concepts (UX) for IoT solutions in a lecture.

At the end of our presentation, which showed a user’s work processes, from the data acquisition of a real “Thing” to the visualization of live data in the dashboard using a Digital Twin, there was a very stimulating discussion. Two points were particularly interesting here:

  • In many application areas, the topic of customer journeys is high on the agenda – which confirms the current trend.  
  • It is essential to develop software for users – which was also a consensus.

The evening was dedicated to Industrial IoT. As a moderator, I hosted a discussion with representatives from various enterprises and software companies, such as Miele, Dürr Dental, Codecentric or akquinet. An intensive discussion around the predominant topics of the industry 4.0 took place here. In addition to the choice of the control electronics or the wireless standard, this also includes questions as to whether an IoT solution should be operated in a cloud. The reasons for solutions in a cloud are of course the convenience and the relatively efficient and simple scalability with regard to the number of “things” to be managed. On the other hand, managing the software on your own servers (on-premise) means that confidential product or customer data really won’t leave your premises. The discussion has confirmed my assessment that both approaches have their advantages in practice and are applied accordingly.

One of my personal highlights at this year’s building IoT was a negative hit list of IoT products, so-called IoT failures: products that have massive security gaps, such as open data interfaces. Some “classic” vulnerabilities were already known, such as unaltered standard passwords that allow data misuse. Others gaps really surprised me: such as a smoke detector of a well-known brand, which is already equipped with a microphone (?!) as standard, which in turn allows unwanted monitoring in living rooms.

Why is there a microphone in a smoke detector?  We can’t say that for sure, at least it’s not in the customer’s interest and causes a massive loss of trust in technology. And that is precisely the point: acceptance of new technologies requires trust. And this is becoming more and more important with increasing digitalization.