Einzelne Aufgaben eines Interfaces sollten neu gestaltet werden. »Design and build …« war dabei das Motto. Die Lösung sollte also über (programmierte) Funktionsprototypen validiert und weiterentwickelt werden.
Die Funktionen des Interfaces sollten also nicht nur konzeptionell erdacht und visuell gestaltet werden, sondern soweit wie möglich programmiert werden. Diese Herangehensweise führt die Studierenden näher an die Möglichkeiten und Begrenzungen einer Technologie heran und offenbart Denkfehler besonders deutlich.
Das Fokus in diesem Projekt lag nicht darin, ganze Konzepte für Applikationen oder Services zu entwickeln, sondern die Komplexität in “einfachen” Aufgaben zu erkunden und Interface-Lösungen dafür umzusetzen. Die Ausgangsfragen, die dieses Semester bearbeitet wurden, lauteten beispielsweise:
Wie kann eine Smart-Home-Steuerung besser mit dem User kommunizieren und mögliche Automationen anbieten?
Wie kann ein Smartphone als Eingabegerät für (kollaborative) Erlebnisse genutzt werden?
Wie kann es Designern ermöglicht werden, Sound in Websites und Applikationen einzubinden?
Wie können Blinde beim Einkauf von schwer unterscheidbaren Lebensmitteln unterstützt werden?
Sound is often overlooked and underestimated in digital products, even though it can greatly enhance the experience of these products. When sound is well integrated into the product experience, it can convey important information to users. In doing so, sounds can work independently or in tandem with visual content. Sound can also be key to enabling accessibility or creating the necessary gamification character.
Until now, this discipline of designing and developing sounds in digital products has been reserved for those with a high level of technical understanding. However, designers, marketing personnel and project managers are excluded from this process.
This project aims to address this problem. Sounds are such an important part of digital experiences that they should be designed and flexibly configured by everyone. However, the solution should not remain a pure design tool, which is later further exploited by developers and possibly reinterpreted. Instead, a “production-ready approach” should be strived for. This means that the users of the service can use this solution without the need for a “hand-off” between designer and developer.
To define which goals should always be the focus of design and development during the project, design principles are established for the overall scope of the project.
No Code Interface
It should be possible for every user to manage the sounds of the digital experience, edit them and make them available to the consumers of this experience. Optimal for those who have no skills around programming.
The integration of the tool should be very simple and accessible to everyone. With a ‘single line of code’ approach, the implementation hurdles should be made as low as possible.
Enable (simple to complex)
The easy-to-use sound tool should simplify complex editing and composition processes through good interaction concepts.
The tool is intended to create a collaborative environment that brings all participants closer together and creates space for mutual inspiration.
Identifiying our users
In order to better understand the potential users and their knowledge and needs, it is useful to divide the user groups into personas. In this project, 4 personas were identified for this purpose.
It is particularly interesting that there are large knowledge gaps between the actors. For example, designer Malai is very knowledgeable about the overall concept and the target impact on consumers, while developer Anna is comfortable with the code base of the project and Lara from marketing knows what cost-benefit strategy and which keywords or keysounds make sense in the project.
Steve, on the other hand, cares about the quality of the sounds and is good with the necessary effects to get the most out of the experience. It quickly becomes clear that all players have an important function in the team and should work together on the product to fulfill this team effort.
To enable the players named in the previous chapter to work simultaneously and decentrally on digital experiences, the discussion was quickly steered in the direction of a web application. This should be equipped with a classic account management and include collaborative features. In order to transfer the configurations made on the web platform to one’s own product, an ‘npm package’ or code snippet must be loaded into the product. This is provided with a token that allows access to the configuration. This way, the creation of the sound experience can be outsourced and edited on the ‘no code’ interface.
Fullstack Audio Design
An important part in the vision of the project is also that not only the classic web stack can be served by the tool, but any internet-enabled device. So every program on desktop and smartphone, on the web or in the app or even smart devices, such as refrigerators or scooters.
Understand the challenges
In a brief market analysis, attention was quickly directed to other software services that also follow this technical approach. A good example which should be mentioned is mapbox. mapbox is a map service provider and gives the customers the possibility to configure the maps themselves in the web tool and then insert them into the project with a simple code snippet. When testing this interaction with mapbox, we were positively surprised by the simplicity with which configurations can be compiled here.
Make sound interaction easy and accessible
To make the configuration as simple as possible, a simple and consistent way to sound interactions on the web was sought. The choice fell on a configuration package of interaction, sound and effect. These packages can then be assigned to different elements on a website or app. For example, a click and a hover interaction can be created for one or more elements.
Test the outcome
Following the configuration, the compositions are to be made available to selected end devices through a browser plugin before they are made available to all clients. This allows the experience to be extensively tested in a secure environment. Without this feature, a ‘production ready’ service would have been difficult to implement.
After all tests were valid, the experience can be made available for all devices with one click.