Web Components, Project Instances and Console Logs

A Triptych of Contemporary UX Prototyping

Creating new UI elements and floorplans is a challenging task and creative in so many ways, one of which is being flexible while prototyping for software.

Photo by Marvin Meyer on Unsplash

Prototyping

There is a quite large literature supporting the use of prototypes within the design process, but in this article, we would consider the need for a prototype as given — and crucial — and therefore speak further about the methodology for building and using one.

The development of a software prototype from the very first steps of the design process gives us the opportunity to begin testing it directly with end users in real media and conditions. Thus, it offers the advantage of collecting constructive feedback at a very early stage of the design process.

Medium and conditions

A prototype that consists of sketch alike wireframes could be clearly used to map the information architecture and explain the flow, but in order to test the design concept in the proper screen and conditions, the prototype has to look exactly like the final product.

The use of real media and conditions within the usability testing puts up further the requirement for use of a certain kind of technologies, that will simulate and render the design concept in the exactly same level as the final product. This will allow us to capture preciously unfiltered and straight feedback from the end users pretty early.

Flexibility

The aspect of the early stage mentioned above sets one more requirement regarding the flexibility and creativity in using these technologies. Early feedback can be incorporated into the prototype development and influence the design process, triggering an iterative process of testing-collecting-designing-implementing and all over again. In this case, the flexibility relates to the technologies that the designers use to meet this requirement and switch easily among designs concepts and solutions. A flexible prototype schema will support multiple trials with different variants of the design concept, as well as rapid hacks or customizations.

Implementation

There are multiple ways to create a pixel-perfect prototype, and, usually, the preferred way is just closer to the experience and the background of the designers involved. This also includes the available resources at the current moment when the prototype is asked. In this article we would like to showcase the code oriented path for creating web based interactions, by using open source web tools based on HTML for the structure, CSS for the style and Javascript for the logic and for storing demo content.

Architecture

The fact that we use coding in the design phase, does not necessarily mean that all web technologies which are used in the production phase cover our needs and fit to this one as well. There are certain web technologies that address more our needs as designers, among which we can choose those that allow us to reach the desired level of quality and flexibility.

Web Components

Our target is to create a library of re-usable elements and layouts that we will use in order to depict the information mapped on the wireframes and create interactions between the steps. Concept-wise, an element is the smallest interaction unit that can be repeated within one layout or screen; a layout is the arrangement of the above mentioned elements on the screen, and can not be repeated on a single screen. The benefit is though, that both elements and layouts can be included and repeated into other elements or layouts.

The elements and layouts are technically web components, organised in a folder per component. Each component consists of its HTML file that includes the structure; its CSS file with the style information; a JS file including the script regarding its behaviour and dynamic parameters that can be imported; and a JSON file providing the dummy content that we want to use in our demos. In that way, a web component is totally independent from any other that belongs to the same library and it is easily reachable, updatable and extensible.

Following the above schema, there is no data base involved. The reason is that this would demand additional technical know-how which is not regularly part of the profile of a designer, and of course is related to the performance. A connection with a database would raise additional technical requirements in an environment where we are usually supposed to run a demo in offline mode.

Project Instances

The library of web components allows, on the one hand, those who consume it to quickly set up instances of each prototype that they want to develop, and on the other hand, those who publish it to distribute updates.

With a package manager such as Bower, we manage to automate the process of downloading and installing all necessary resources and making it even easier to update them. By cloning the library’s repository, we can have instantly available the latest version of all the components. In addition, a project instance consists in standalone script files, that can be easily transferred and viewed on any terminal with no need for online mode.

The most important in this concept for the designers who consume it is that they can easily adjust the components to the special needs of the project by creating variants or duplicates. This means, that even if they have multiple demos with various customers, they can create instances of the prototype for each customer within few minutes, adjusting further the style or even the language.

Console Logs

The browser console can be used not only while developing, but also while conducting usability sessions for extracting valuable data. The logs can be used as an automated process for tracking user’s behavioural data. The use-case steps of the tasks during each session can be clearly printed and reviewed. For our purposes we used an additional script to store the logs on an external text file after each session.

Even if we do not want to make use of a data base for storing this kind of information, the console can always print an exportable format of a session with each user, giving us an exact imprint of user’s interaction with our software. This imprint could be a measurable artefact for further quantitative analysis of user’s behaviour. This would allow us to visualize and compare the data while summing-up the report of the usability testing.

Summary

The prototype architecture that we explained above comes as a solution or a set of tools to what contemporary UX design is asked to support. This concludes to a very flexible schema, where many people work on different aspects of the same project; this schema is required to be easily accessible and customizable, able to perform in multiple media in real conditions, so as to keep the quality really high!

Although we admit that it is technically oriented, we hope you liked it and would be glad and open to any further comments and ideas!

* The article has been initially posted in SAP’s User Experience Community.