KISS – Keep it Simple, Stupid

Ever heard of the KISS  method? There are some variations on the phrase, such as “keep it short and simple,” but one of the more well-known is “keep it simple, stupid.” It’s a reminder not to “overanalyze the issue.” When we don’t keep it simple, straightforward tasks often become more complex and complicated than they need to be. Overt complexity leads to errors in situations in which accuracy can be critical.

I was recently involved in an UX design project where the customer requested us to design a new and modern interface for a group of technicians maintaining complex machines. The technicians were trained to document their maintenance work on paper, but since SAP ERP was introduced, they were required  to do this in the SAP GUI as well. This complicated their work and took twice as long.

All maintenance activities have to be executed error-free, documented, and signed by the end users. Errors can lead to fatal accidents. So the whole process needed to be transformed to follow the KISS principle  – making it understandable at first glance.

The customer asked us to prepare and conduct a 3-day workshop on-site with their end users  to identify all the necessary steps to maintain the machines and get things done in the SAP ERP system as easily and quickly as possible with a delightful, intuitive and simple UI in the SAP Fiori design.

Prior to the workshop, we heard statements, such as:

  • “All those fields are necessary”
  • “The process has already been optimized, and we need to do all those steps in SAP ERP to fulfill requirements, processes, and legal regulations.”
  • “We can’t make it simpler!”

Does this sound familiar to you? 

I guess many of you have come across similar statements and situations in your daily design and development work. Although at first glance these statements seem valid, simplification is indeed in your reach if you  keep in mind the following three points .

  • Field research is mandatory to understand customers’ needs
  • Personas synthesize and focus design work
  • SAP Fiori Guidelines and stencils speed up prototyping

Field research simplifies

We started the workshop with a short introduction to Design Thinking and then the end users were divided into two smaller teams for field research. We saw the complete cycle of line maintenance activities and could interview the technicians at their workplace. This way, we had a good impression of their real-world environment and could build empathy and trust with our end users.

We needed to make sure to  really ask the end users and not the customers’  consultants, managers or help desk experts. This is important because end users’ answers and pain points concentrate mainly on their work tasks. All the other stakeholders are very knowledgeable but not really in the shoes of the end user, and the research results coming from other stakeholders will be different  – if not just plain  wrong.

Without field research, developers and designers might take out features and data fields needed by the end user or process. As Albert Einstein once said , “Everything should be made as simple as possible, but not simpler.”

Field research is the basis of design and development and a great simplifier. With this site visit and real-world observations, many design alternatives had been resolved and possible questions had already been answered.

Personas simplify

As Donald Norman says,  “In my opinion, no single design is apt to be optimal for everyone.”. That’s why reducing the overall complexity to a persona – a description of a typical user for a particular use case or scenario – helps to optimize the design significantly. Once we have identified and verified the persona for whom we design and develop new interfaces, we can shape the whole Design Thinking process of ideation, UX sketching, and prototyping.

SAP Fiori Guidelines simplify

In the process of creating prototypes, we started scribbling user interfaces with the technicians according to their requirements and processes. The scribbles were then presented to another group of end users for validation. This way we collected and verified “the wisdom of the crowd.”

Back at the office, the transformation of workshop results into clickable prototypes started.  We found that concepts and controls presented in the SAP Fiori Design Guidelines simplified the design work. SAP Fiori stencils and floor plans might not always fit every requirement, but we found that they helped us significantly to meet our customer’s requirements. In particular, they helped us to transform our scribblings from the workshop into clickable prototypes. The possibility to request UX consultations with our prototypes made things even easier.  We found that the Overview Page floor plan fit our customer requirements really well, as it greatly reduces the number of interfaces an end user has to learn and use.

After the initial prototyping, we packed our bags and rushed back to our customers with the clickable prototype. There, we did the next end user testing in two groups:

  • one group with the participants of the first workshop – to see if our design fitted their use cases ;
  • and another group of end users who hadn’t been involved – to get new feedback

Good design is (simply) good business

Our customer and end users were delighted with the results and gave us great feedback about the process. Our design project has been handed over to development, and the end users are now eager to get the SAP Fiori UI’s we designed. As Thomas J. Watson of IBM once said, “good design is good business.”

Simplification? It’s possible and within our reach. The design and development of SAP Fiori user interfaces can be kept simple if we:

So the statement “Simplification? It is just not possible” isn’t true. Design Thinking, the SAP Fiori Design Guidelines, and the available UX technologies allow and enable a “KISS”-driven approach.

Not logged in