Author: Johannes Bergsmann, Software Quality Lab<\/p>\n
In today's world, dominated by attractive smartphone apps, software that, while good, lacks a modern and appealing user interface (UI) hardly sells anymore. However, a pretty interface alone isn't enough to impress users in the long run. What should you consider when designing a UI? Which techniques and methods can you use to create user-friendly UIs? Where should UI design be positioned in the requirements process? Which specification techniques are helpful from the initial idea to the finished UI design? These questions will be addressed in the following article.<\/strong><\/p>\n When considering the levels of requirements engineering (Fig. 1,\u00a0PDF<\/a>), it becomes apparent that the specification of the UI (masks and output of the system such as reports) should primarily take place in the detailed specification at the lowest level.<\/p>\n This is advisable because other aspects that significantly influence the UI should be clarified and defined beforehand, such as the goals, system boundaries, processes and workflows, and the overall requirements. If these points are not clarified in advance, there is a risk of getting bogged down in the details of the user interfaces and overlooking important aspects that also affect the UI architecture, subsequently leading to significant effort in redesigning the UI.<\/p>\n However, the topic of user experience (UX) or usability of the system should ideally begin earlier, with stakeholder analysis and processes, as this is where general requirements for the "delight factors" of the system and the process design are defined.<\/p>\n User interface specification is the link between user requirements and technical solutions (Fig. 2,\u00a0PDF<\/a>).<\/p>\n Unfortunately, this is often neglected during specification and implementation. However, by making good use of this key position within the system definition, a shift in perspective for developers could potentially be achieved. The focus should be more on the user and their tasks, instead of getting bogged down too early and intensively in the analysis and definition of the technical solution. The issues visible to the user, which are addressed through usability or user interface engineering, must also be appropriately integrated into the software development process.<\/p>\n The Kano model defines 3 factors that have different meanings from the user's point of view (Fig. 3,\u00a0PDF<\/a>).<\/p>\n Basic factors\u00a0<\/strong>The system must fulfill these requirements without the user having to explicitly request them beforehand. Failure to do so usually leads to significant dissatisfaction. However, fulfillment does not automatically lead to a positive experience. Often, these are unconscious requirements that are not explicitly demanded or may even be shaped by an existing system (implicit requirements). An example is the ability to make phone calls with a mobile phone.<\/p>\n Performance factors<\/strong>\u00a0The system should fulfill certain requirements. Fulfillment generally generates satisfaction, but not necessarily enthusiasm. If (a few) performance factors are missing, stakeholders usually still accept the system. However, satisfaction decreases with each missing performance factor. Performance factors are consciously and explicitly demanded by the stakeholder (conscious requirements). One aspect that must also be considered in the planning and roadmap of systems is the fact that basic factors become fundamental over time and with user interaction. An example of a performance factor is that you can also surf the internet and take decent photos with a mobile phone.<\/p>\n Factors that inspire<\/strong>\u00a0The system can fulfill these requirements, and this fulfillment generates significant satisfaction or enthusiasm. Users usually don't expect these factors and therefore don't explicitly request them (unknown requirements). They need to be presented with them or have the opportunity to try them out. Satisfaction increases relatively sharply with each "excitement factor." Here, too, a change aspect must be considered: over time and with use by the user, "excitement factors" become "performance factors." An example of an "excitement factor" is that the mobile phone can also measure blood pressure, temperature, and daily calorie consumption. "Excitement factors" are those characteristics of a system that have the greatest impact on usability and the positive user experience of the system.<\/p>\n The basic process for specifying UIs is shown in Fig. 4 (see\u00a0PDF<\/a>) shown. To create a user-oriented and systematic UI, one should not start with the design immediately, but rather conduct other considerations and analyses beforehand. The goal should be a "user-centered interface".<\/p>\n Before starting prototyping or detailed user interface design, a systematic task\/process analysis should be conducted. Flowcharts\/process diagrams are a good tool for this. Tree diagrams help to gain a hierarchical overview and to gradually move from the general to the specific. (Business) processes are the basis for almost all system features. Therefore, the process overview should be created as soon as possible; the detailed specifications can then be derived from it or based on it.<\/p>\n These specification steps are not a sequential process, but should or can be traversed iteratively.<\/p>\n For the initial graphic design, a (quick) hand sketch is usually sufficient (Fig. 5,\u00a0PDF<\/a>Based on this, initial discussions, changes, and clarifications can take place. The detailed UI can then be systematically developed based on these initial rough sketches and discussions. The next step should then be the clear structuring and definition of the UI's layout (Fig. 6).,\u00a0PDF<\/a>).<\/p>\n Sketches and wireframes are the core of every user interface production process. They should be based on predefined use cases and processes and specify which screen elements must be present in each interaction step of the workflow. They are typically rendered in black and white, focusing on functional implementation rather than visual design. Annotations for each screen element provide developers with guidance for their implementation.<\/p>\n In the final step, the finished design is created in the form of detailed sketches or prototypes (Fig. 7,\u00a0PDF<\/a>).<\/p>\n The client usually wants to see visual designs as early as possible. This carries the risk of over-detailing and unnecessarily restricts the designers later when actually developing the UI. Defining details too early also wastes time and money due to unnecessary discussions about details that will inevitably be changed countless times in subsequent iterations.<\/p>\n When designing the user interface, it's crucial to focus on the essentials. The basic principle of "from the general to the specific" should be followed. Sketches or wireframes are a good tool in the early design stages because they convey a sense of incompleteness and don't (as much) tempt you to discuss details too early. They help to explore and discover the user's visual preferences.<\/p>\n User Journeys\u00a0<\/strong>They focus on the user and their workflow. They are a high-level description of the tasks or processes that the user performs with the software. In other words, they represent the user's interaction with the software. Typically, process diagrams are used to visualize user journeys (Fig. 8).,\u00a0PDF<\/a>).<\/p>\n Storyboard<\/strong>\u00a0This is another way to represent the interaction process of a user with a system. In principle, this is similar to the user journey, but with less focus on the exact workflow and more on the rough visualization of the user interface in the context of the desired function. Typically, a sequence of wireframes with explanatory text is presented here (Fig. 9).,\u00a0PDF<\/a>).<\/p>\n Storyboards are a valuable technique and visual aid for discussing and specifying system interactions with the user. They reveal the functionality of the elements and the navigation scheme early on. Requirements are visualized without yet being implemented.<\/p>\n The user interface specification is a crucial part of requirements engineering. UI topics permeate all levels of the requirements document. The desired and defined system behavior strongly influences the design of the UI. Therefore, systematic planning and structuring beforehand are essential.<\/p>\n The user interface (UI) is an important basis for discussion with stakeholders. Sketching and wireframes support early specification and discussion. In addition, there are a number of different tools available for UI specification.<\/p>\n The final UI design should be determined as late as possible to avoid getting bogged down in details too soon and to avoid the effort required for detailed work that is usually changed in later iterations.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of implementation\/embedded and real-time software development.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in the field of implementation\/embedded and real-time software development is available.\u00a0here\u00a0<\/strong><\/a>Available for you to download free of charge.<\/p>\nUser interfaces in the context of requirements engineering<\/h2>\n
User interfaces in the context of requirements engineering<\/h2>\n
User Interface Specification Levels<\/h2>\n
From system behavior to UI<\/h2>\n
UI design and specification<\/h2>\n
Sketches and wireframes versus visual design<\/h2>\n
Further UI specification techniques<\/h2>\n
Some key factors for success in UI specification<\/h2>\n
\n
Summary<\/h2>\n
\nImplementation \u2013 our training & coaching<\/h2>\n
\nImplementation \u2013 Expertise<\/h2>\n