The idea

We at coeno have been dealing with the methods of usability engineering for some time now and are convinced of the approach of using context interviews to inquire about the experiences of the user and derive requirements and usage demands from them. Thus the user is involved in the requirement process in a structured way. In some projects, e.g. for Kabel Deutschland and Xvid Solutions, we have already worked successfully in this way ...and yet the user is often not asked "for time reasons" or the product management directly specifies the feature set.

We decided to take a closer look at the two methods and without further ado carried out a small project in two teams. The goal of the project is to develop a concept for a mobile app that supports the sale of ice cream from a Piaggio Ape and makes it attractive for the user. "Team # PM" works together with a product manager and develops the concept based on a comprehensive feature list.  "Team # User" works according to the pure teaching of usability engineering, as taught at the Fraunhofer Institute.

The procedure

At the beginning the "Team # PM" develops a Scopematrix. This contains the requirements compiled together with the product management as well as their evaluation and prioritization. In the second week, the team develops the central idea and interaction paradigm. From these, the rough concept with the core views and processes was derived and visualized with the help of wireframes. The team decided to work out different rough concept versions and then weigh up how the mobile app should be designed in detail. The different concept approaches were brought together in a joint workshop.

"Team # Users" starts with contextual interviews, for which six relevant users - people who like to eat ice cream - were selected. In the second week, the interviews were written down in context scenarios, an essay written in simple language. The scenarios are the basis for the derivation of requirements ("implied needs"). "A requirement is a necessary condition that enables the purpose to be fulfilled efficiently in a given situation (context).". DAkkS Deutsche Akkreditierungsstelle GmbH (2010): "Guidelines for Usability Version 1.3″. URL: http://www.dakks.de [18.10.2013].

Based on the requirements, the usage requirements were derived, from which the concrete demands on the mobile app are derived. The result was 66 requirements and 148 usage requirements derived from these. These were assigned to core tasks and subtasks in a longer workshop using a simple task model. This resulted in a structured list describing the features for the mobile app. The ideas for the interaction paradigm and concept were developed very quickly in the "Team # Users", since everyone had already worked very intensively with the users and important functionalities.

After three weeks, both teams were ready for us to present the concepts to each other.

The result

When comparing the results, it becomes clear that both teams agree on the definition of the main features "location" and "assortment". However, a closer look at the details reveals a number of significant differences.

Location/Navigation: It was clear to both teams that the customer must know the location of Piaggio Ape and also establish a link - at least in thought - to his own location. Navigation to the Piaggio Ape starting from the user's location is provided for in both teams, but is clearly given higher priority in the "Team # User".

Assortment: The teams agree on the necessity of displaying the ice cream varieties as well as other information such as additives, information on production and ingredients. In addition, the users would like to see new varieties and special flavors accurately labeled. These details are therefore more in focus at "Team # Users". "Team # PM" is planning further features such as "Ice cream of the day" and "Voting on future ice cream varieties" - here we will see whether the users accept them.

User reviews: "Team # PM" is planning general user reviews of ice cream varieties. The user surveys have shown that information about the most popular types of ice cream is quite sufficient.

Alarm: Both teams provide an alarm function. It is interesting to note that through the user survey, in addition to the need for the "Alarm" feature when Piaggio Ape is near, other interesting reminders, such as temperature-dependent alarm and alarm when the favorite ice cream is available, could be derived.

Social: The link to social media networks is a mandatory feature for "Team # PM", we don't know whether the user needs it - from the context interviews of "Team # users" it has only been mentioned once in connection with the topic of eating ice cream.

Editorial content: Around the topic "Eating ice cream" there are still many details that could be derived from the context interviews, such as being able to recognize what is behind an extraordinary flavor, what types of packaging are available, what distinguishes a particular flavor or whether the ice cream was stored/transported in the best possible way.

Design: In addition, findings from the context interviews also have an influence on the concrete design of the application. For example, "Team # Users" chose a color scheme that puts the user in a summer mood and reminds him of sun and heat. In contrast to "Team # PM", which is more reminiscent of the character of Piaggio Ape and focuses on retro elements and pastel shades.

In any case, it has become clear that the involvement of the user leads to a lot of information and knowledge that has a positive influence on the result. Thus, in addition to objective findings regarding user needs, important findings can also be derived with regard to the emotional level. The concept developer also has a much more detailed content basis for deriving features and, because of the naming, better arguments for your prioritization. In addition, the result has led to conclusions about the business model. Team # Users now always let the Piaggio Ape drive in the same city district, because "eating ice cream" is a spontaneous need, which the user does not make dependent on timetables and routes.

In summary, it was a very exciting experiment in which the whole coeno team learned a lot. We will continue to work on this topic and we are working on making the user more and more a part of our projects.

For us it is clear - the involvement of the user leads to a better result and has a lot of influence on the creation of a positive user experience!

‍

Thanks to all involved!