This article was inspired by two interesting days at the GUI&Design conference that took place just recently on 8th and 9th December in Fürth, Germany. The conference audience consisted of professional user experience designers and developers and the talks and workshops focused on Microsoft user interface technologies such as WPF and Silverlight.
Not only this article is a spontaneous creation – one of the activities I participated in during the conference was, too: Clemens Lutsch, User Experience Evangelist at Microsoft, asked me to join a discussion panel in order to conclude the first conference day and discuss concepts and roles in the UX domain with regard to aspects that are challenges in our daily professional work.
For me this was an excellent opportunity to discuss a term that we have introduced at Centigrade a couple of months ago: “user interface design engineering” or a bit shorter “UI design engineering”. Having used the term just internally in the first place, we started to bring it up in conversations with our clients and partner companies more and more frequently – with great acceptance. When I brought up the term during the panel discussion, I observed similar acceptance from the audience and my co-speakers – almost as if the term closed a gap that many professionals felt has existed for quite some time. It was even picked up by other conference speakers, right the next day, which motivated me to shed some more light on the term and its meaning. So, what is UI design engineering, anyway?
For us at Centigrade, UI design engineering is a fundamental activity in the process of creating successful and enjoyable user interfaces. It is about bringing all those concepts to life that would otherwise melt away in the communication desert between designers and developers (as pathetic as it may sound it is still a suitable metaphor). UI design engineering is about all those (mostly dynamic) details in a user interface that are quicker and more accurately “just done” rather than being written down and then delegated to a software engineer through a prose specification documents. In this respect, a “UI design engineer” is faced with tasks such as creating micro-interaction prototypes, storyboarding animations, defining dynamic layouts or integrating visual designs into real software.
Traditional meaning
The sub-term “design engineering” is not new. It is commonly used in various disciplines such as electrical, mechanical and industrial design and even in building engineering. Actually, Wikipedia has a comprehensive definition on the role of a design engineer. It does not, however, make reference to software user interfaces. If you read the Wikipedia article with software user interfaces in mind, though, there are quite a lot of obvious overlaps. To name just a few:
“The design engineer takes care of the total system as well as inner workings/engineering of a design”. Definitely something that can be applied to the design of a total software system and its user interface: A user interface design engineer needs to care about structuring and naming design assets (e.g. as color or font resources) so that they integrate with the entire system architecture (“total system”) but also needs to know nifty details about single pieces in the system, e.g. how a mouse-over state of a button behaves in on a micro-level (“inner workings”).
“The design engineer usually works with a team of engineers and designers to develop the conceptual, preliminary and detail design and the most critical parts”. Again a hit: regarding the development of a user interface the design engineer needs to work with interaction designers, visual designers and “real” software engineers during the entire UI development process. Not only should UI design engineers have an eye on whether concepts are feasible in early stages of the project, they should also be actively involved when it comes to implementing “critical parts” of the system. And the UI’s dynamic behavior is definitely its “most critical part”.
“…synthesis is paramount for design engineers.” Putting together things that may loosely exist “somewhere” is definitely a task for every UI design engineer. The UI design engineer needs to implement and integrate stuff that other people have planned (e.g. screen mocks or interaction paradigms) so that it is compatible with everything that is already existent in the system.
“The next responsibility of many design engineers is prototyping. A model of the product is created and reviewed.” Do I really have to say something about this one? The model of the product in the UI context of course is an interactive software prototype that makes relevant interaction dynamics tangible. The review (and potentially iterative refinement) of prototypes should be an integral part of every professional user interface design process.
“The design engineer may follow the product and make requested changes and corrections throughout the life of the product. This is referred to as ‘cradle to grave’ engineering.” Software is never finished – and this applies to the user interface, too. Therefore, it makes sense to have a UI design engineer accompany the process from cradle to grave (which hopefully lies far in the future). The UI design engineer is the “design memory” that can tell when certain designs in the system have change and why, not least because he/she knows how to deal with modern versioning tools such as Subversion, Git or TFS.
Delimitation from “User Interface Engineering”
Sometimes, in the context of UI development one might be faced with the term “user interface engineering”. This should not be confused with “user interface design engineering”. There are lots of commonalities between them, but also some rigid borders. Here is how the two terms differ:
UI engineers write object-oriented code (e.g. as in C#) while UI design engineers write declarative code (e.g. in XAML).
UI engineers have to know business objects in detail (such as data models or DTOs) and are responsible for establishing data bindings that tie the view to the presentation logic.
In this respect, the UI engineer also has to have an eye on performance aspects: data bindings are elegant to use and easy to handle, however, can have a negative impact on the entire system performance, which sometimes can only be identified through profiling activities the UI engineer carries out. The UI design engineer cares about performance, too, but more with regard to visual appearance rather than logic. If, for example, a visual effect can be accomplished through a simple border rather than a pixel-shader-based drop shadow effect, the UI design engineer may decide to favor the first one in order to ensure acceptable performance also on older machines with weaker graphics cards.
UI engineers have to consider memory leaks. As they write object-oriented code (freely instantiating and referencing objects), they are always in a situation in which they could potentially cause memory leaks e.g. through circular references. For UI design engineers dealing with objects is much more restricted due to the fact that declarative languages hide a lot of possibilities and with that a lot of potential threats (e.g. UI elements can only exist in a directed 1:n parent-child relationship).
It is common sense that modern programming involves writing a lot of unit testing code. “Test coverage” became a measurement for code quality. Therefore, UI engineers have to write unit tests and UI automation test cases. UI design engineers cannot write test cases as they only have the “restricted power” that the declarative language provides them with. However, in the future it might be more and more the case that UI design engineers record UI interactions and define assertions. These recordings are then replayed anytime the UI has changed and revalidated against the defined assertions. The latter approach, of course, requires a capable test authoring environment which is currently hard to find.
To wrap up this comparison in just a few words: the UI engineer is a software engineer, while a UI design engineer is a designer with engineering skills.
What skills does a UI design engineer possess?
To pick just one typical engineering skill a design engineer must possess: the definition of a dynamic, resolution-independent layout that behaves properly in diverse contexts with different localizations or display sizes. This requires a sharp understanding of complex logical chains while at the same time being able to distinguish good proportioned layouts from bad proportioned layouts. In addition – and most importantly – it requires being able to fill specification gaps that a visual designer or interaction designer has left because he has not foreseen all implications in the first place. This is not to say that visual designers or interaction designers do not have the skills to identify such situations – the point is that they cannot practically identify them because they do not work with the real thing, i.e. the declarative code that brings the design alive and thereby provides immediate feedback and a tangible user experience. During direct collaboration between UI design engineers and software engineers working on exactly the same solution though, rough conceptual deficiencies or inappropriate interaction mechanisms are unveiled at some point during development. This, of course, does not render proper usability testing unnecessary, however, it definitely “greases” the entire software development process.
New, yet timeless
The term UI design engineering is rather new due to the fact that we coined it as a consequence of a (still) very recent user interface development ecosystem around WPF and Silverlight.
Admittedly, the tools that are commonly used to leverage these modern technical possibilities – Expression Blend and Visual Studio – are available for quite some time now. But never before did I have the feeling that there was as much shared understanding in terms of what capabilities and responsibilities a person working with Expression Blend must possess. One strong and, in my opinion, beneficial recent development is that Expression Blend is no longer regarded as being a mere design tool. Roughly speaking, it is finally considered a tool that can only be handled by designers that have “special powers” – design-development hybrids strong at shifting right-and-left-hemisphere thinking. Or, actually, UI Design Engineers.
Future Outlook
I believe that there is absolutely no way back to a rigid and stone-walled separation between development and design activities. Even technologies other than WPF and Silverlight in the future will as well be judged according to their design-development-collaborative capabilities, not only according to their “hard” features such as performance or platform availability. It is no coincidence that Nokia’s brand-new Qt Quick comes up with two tools (QML and Qt Creator) that enable UI design engineering activities in a comprehensive way. Obviously, the combination of a declarative syntax (XAML or QML) and a strong WYSIWYG environment (Expression Blend or Qt Creator) is key to this discipline – rather than the actual syntax or target platform.
Considering this, I have a strong feeling that the idea, which we see in the term “UI design engineering”, is here to stay and will last beyond the technologies that sparked the use of the concept at Centigrade in the first place. In any case, it is very nice for me to see that both disciplines – traditional software engineering and traditional user interface design – will grow together even more in the future. And UI design engineering is the glue that will hold them together.
All trademarks or registered trademarks are properties of their respective owners.
