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.


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.


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.


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.


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.


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!

Not logged in
  • Clare Johnson   1 year ago

    Thanks for this inspirational approach to prototyping as part of UI design. Here are a few thoughts:

    I am currently working on a development tool. The tool and its environment already exist and are satisfactory, so my focus is on certain problem areas. Therefore, I would not prototype the whole screen, but just these areas. For example, I might use an image for 75% of the screen, but make the adjacent screen area quite interactive. Would this work? As you mentioned, with a pixel-perfect prototype people expect everything to work. I would need to make clear to testers that they can’t click everywhere. Or, maybe I would need to find a way to test the area in question in “isolation”. Or maybe this idea is not suited to this prototyping approach…

    You discuss the potential for testing with such prototypes. They are certainly also good tools for communicating with development or product management. They really represent the target look and feel. Thus a related question: are your development teams able to reuse web components, CSS or other parts of your prototype, or is this not a goal?

    • Konstantinos Drachtidis   1 year ago

      Thank you, Clare! 🙂

      Regarding the development tool you mentioned…
      If you are about to invest on the interactive part, this would probably be contradicted by the static area where the user would “pause” his interactive flow. Isolating it, on the other side, would perhaps create gaps on this flow, preventing an holistic approach from the side of the user, and, eventually, the contribution of the moderator would be needed.

      There are, of course, concepts that could be borrowed from mobile UX design or even game design, for building a quick walkthrough like a tutorial, introducing the user to the tool and to what is available and what is still locked. That way you could combine the images with the web components and not only make use the isolation profitably, but also creatively.

      Though, if I understood it correctly, you could ideally use your own custom elements within the existing environment and test them. Since the WebComponents are just HTML files that can be easily stored and included into a container, they could be part of any more sophisticated web based infrastructure. But again, that would demand from your side to run the tool properly, on its server with all technical requirements filled.

      Regarding the collaboration with the developers… WebComponents, as pieces of code, are pretty clear documentations of design concepts, which – theoretically – could not be misinterpreted. So, this is definitely the first goal, to use common channels of communication with the dev teams and code is a common language that could be used. Moreover, if the infrastructure makes use of the same technologies, i.e. HTML, CSS and Javascript, then yes, the WebComponents could not only be reference points between designers and developers, but also copyable parts.

      Hope I helped a bit 🙂