You are a Developer? So, you are a UX Designer.

The term UX design is used very often nowadays. In most cases it’s either used as synonym for interaction design, usability professional or a similar denotation or as conglomerate of all of these disciplines. It is recalled that UX design is not only a phase, but that it should be applied throughout all phases of a project. For me, the boundaries of the term are still set too narrowly. Everybody involved in the development of a product has significant impact on the resulting UX. Usability engineers, interaction designers, visual designers, design engineers, project owners and developers.

Yes, you got it right: developers are UX designers[1] as well. They have to make a lot of design decisions: What kind of architecture do we use? Can we optimally use the hardware components? Can we implement the concepts on target devices performantly or do we have to adjust the concept? Can we implement the concepts with appropriate effort?

Developers have a significant influence on the resulting UX. From my perspective as an interaction designer it’s my task to maintain the relationship to the developers and involve them stronger in the communication in early concept phases.

Practical Example: Multi-touch Gestures

A while ago we designed a gesture control for multi-touch displays in a project from scratch because you can’t buy this right off the shelf. After the rough concept and the analysis of existing approaches – who wants to reinvent multi-touch gestures in the age of iPhone and iPad? – we started with the detailed concept. An important difference in this case is that the next participating discipline after the concept phase was the development instead of a design discipline, like usual. That means cooperation mainly happened between the interaction design and the development.

Cooperation between Design and Development

And this seems to be a sore point, as my experience has shown: You meet more and more developers at UX conferences because they notice that there is a gap at this point.

Everybody speaks about integrating the UX design methods into the development process, but for me it seems that only a few teams are actually doing this.

But what does this integration mean? For me it doesn’t mean working side by side but working together. Not communication between teams but communication in the team. Because we are a team. Like a football (soccer) team with different positions.

A football team of ux designers: usability engineers as playmakers, interaction designer as bridging of the midfield and developers as strikers.

The team needs to work together, communicate with each other and speak one language. And you have to approach each other if you want that to work. And to accommodate developers: What do they love more than powers of 2 and numerical series which begin with 0 instead of 1? You’re right: We are talking about state charts.

Developers do love state charts

The first thing about state charts I learned was a (unnecessary) form of describing a drinks dispenser which will provide you with coke or water if you insert some coins.

All states, from “idle” over “counting coins” to “give change”, are listed and connected with their following states.

State charts are a good idea if you want to specify a concept. You do not necessarily have to do it for a drink dispenser, though.

During my work as an interaction designer I learned how to work with and appreciate state charts. They are a great method for designing and describing concepts. During the design it’s never easy to capture the whole thing exactly and completely. And this problem shows up during the implementation at the latest. State charts help addressing this problem through structured proceeding during their creation. You can consider all possibilities and sequences of interactions more easily because you can identify them systematically. This even makes developers happier because on the one hand the concept description is less incomplete and on the other hand they have their state chart.

In the case of the multi-touch gestures the state chart emerged as an excellent way to describe this concept. Thereby we had a great basis for communication and development, which explained the basic idea properly and which could be improved together with the developers. We made several iterations until we created a version, which we all were satisfied with.

The best tool to get UX into your development process: communication.

Another important thing for collaborative work and a common language is a shared tool, which enables working together on the same documents. In the case of the state charts we decided to use Microsoft Visio, which I personally don’t like. But still it is conducive for the cooperation.

So the state chart evolved to a “beautiful” and clear diagram (the “beauty” was very limited, because Visio turned out to be hard to master and you had to find some workarounds if you wanted Visio not to destroy all the connections between the states).

We could not fix every issue in our collaborative development process with a state chart or with Visio. But every now and then you just have to try something new. Not a scientific but a pragmatic approach. It is hardly possible to define the individual parameters of the gestures (movement thresholds[2], hold timers[3], etc.) in advance, because the hardware is crucial as well. There is no tool for this. The best way is – very traditional – to get together in one room. So we met for a workshop. We discussed the concept details and the technical implementation: What is possible? What’s not? How can we do it? And what else do we need?

Testing for fine-tuning

In the case of the parameters of the gestures we came to the conclusion that we needed them editable in a test application so that we could set them up and test them on different hardware platforms.

Now the developers could define the architecture of the implementation of the multi-touch gestures. This was not easy due to Microsoft, which introduced challenging tasks not only in the context of Visio. Also Windows Presentation Foundation (WPF) was not easy to handle regarding the processing of gestures. But the developers found solutions to implement the desired concept with an appropriate amount of effort. In addition we had some issues with the hardware. We experimented and tested a lot (Paint works pretty fine with multi-touch gestures, by the way), so that we could get the most out of the current generation of industrial PCs and multi-touch panels.

The result is great. At least if the hardware allows it. But the team can be proud of the collaborative and successful work.

Conclusion

Everybody who is involved in the development process of a product has significant impact on it. Therefore the cooperation between every team member is crucial. Because everybody is an UX designer. A common language in a team is essential. And state charts are great regarding cooperation between interaction designers and developers. By the way, with this in mind you are not far from establishing a UX culture in an organization, which is a rewarding topic for advanced readers.

Footnotes

[1] The term „UX designer“ is a reference to the term composition of “UX” and “designer”, which is used very frequently nowadays, knowing that a person’s perception and responses, as the DIN EN ISO 9241 defines user experience, can not be designed.

[2] Threshold, which triggers the recognition of a movement

[3] Time, after which a hold is recognized