an interview with an interaction architect

by Christoph Evers

the goal

When I thought about a topic or a special focal point for this essay there were some interesting parts in the large field of interaction design. Among this have been the entire design and development process, the project view of interaction design, the design elicitation, design evaluation, client/user/designer relationships and much more.

But when deliberating all those topics the most interesting question for me overall is the design space exploration at the beginning of the design and product development. For me it seems that understanding the problem space is one of the most important and essential part for the process and the resulting product, according to a product which meets the requirements and fulfils the user’s wishes and achieves finally satisfaction for them.

In my opinion this part should not be neglected in any design project and my thought has been to take a look into current practice of today’s interaction designers.

This essay is intended to be a small, I want to say, some kind of comparison of my theoretical knowledge gained until now and the practice in a company dealing with human–computer interaction interfaces.


The interview has been subdivided into three parts. The first part should briefly explore the domain of the interviewed interaction designer. This means in special the company where he works for and the job he practices and it is not supposed to drive the general discussion.

The questions in the main section of the interview deal with the design space exploration and understanding of the problem space. This part contains the most questions and is mainly used in the following discussion.

The last section including two questions can be more seen as a bonus part which includes personal interesting topics for me and is intended to be rounding off the interview and the discussion. Those questions will be also not taken into account for the main discussion.

Before starting the interview it was, beyond considering the main topic itself, very important to think about the type and order of questions. In my case I started with very general questions to became more detailed in the end about the problem of design space exploration.

The person I interviewed is Peter Sikking, an interaction architect at man + machine interface works which is located in Berlin, Germany dealing primarily with interaction architecture, based on of 13 years of experience in interaction design and development.

Christoph Evers: In what kind of company do you work and where is its main focus on? Which kind of ‘products’ does the company develop?

Peter Sikking: I am the founder and principal interaction architect at man + machine interface works. We provide concept and structure for the user interaction of software. Methodically we investigate the interaction that optimally realises the project goals.

ce: How would you briefly describe your everyday work according to interaction design?

ps: The interaction architect is the person on the team who leads the development of the interaction concept, and who ensures that the concept stays intact and compact while it morphs trough incorporation of project feedback and usability testing.

An important service of any architect is mediation. Enabling that the managerial, technical and usability sides of the project can communicate with each other at all.

ce: What do you like the most regarding your job?

ps: The Zen‐moment when ‘you got it.’ When you have found the essential solution for a particular interaction problem.

ce: Have you always been working in the interaction design field?

ps: I have always been in user interface, but at the beginning of my career I have spent quite some time on programming. That experience still comes in handy when working together with developers.

ce: Do you use predefined (process) models for designing/developing your products? If yes, what kind of models do you use?

ps: Of course my company has a standard process for structuring our projects, and of course it is proprietary. It is the reflection of my 13 years of professional experience.

I believe that the proprietary processes of an interaction architecture firm form its heart and soul.

ce: When you start a new project, what is a common way in your company to do this? What are the first steps, especially important to you?

ps: The first thing I do is to sit down with the development team and write down the product vision. This defines what we are creating, the value it should deliver, and to who.

The result needs to be sweet and short, a couple of paragraphs, to be used as a tool. All further methods, evaluations and decisions are then based on this product vision.

ce: Do you use methods and/or tools when exploring the design space and establishing the requirements? If yes, which special methods/tools are these?

ps: The product vision is of course very important to me. This is the inner force of the project team. Further I focus on the job or experience the software/website is suppose to support.

To do that I apply my methods for exploring functionality, user types and user scenarios.

ce: Do you have sometimes (or frequently) problems gathering all the required information you need? How do you solve those problems?

ps: Most methods I use in the early stages are actually geared towards information gathering and digesting. By working with the development team we have a constant feedback loop, where small knowledge holes are constantly filled.

ce: Do you feel sometimes restricted in doing this work (through the user/client/contracts/time)?

ps: There is always a constraint in time and development resources for the actual development of the software. Interaction architects are constantly negotiating with the developers what is feasible.

ce: Suppose you do not have any restrictions, is there are (special) point when you stop the exploration process?

ps: If there were no external restrictions, there is always the internal one of keeping your job interesting and moving on to the solutions phase. The solutions phase itself is terminated by the Zen‐moment.

ce: Are there major differences in design space exploration if you start developing a new product from the beginning compared to improve/change an existing one?

ps: The difference lies only in the ‘existing stuff’ you have to evaluate, before moving on to creating solutions. You can evaluate ideas, plans, sketches, mock‐ups, prototypes and existing software. What you will encounter at the customer will vary.

All solution creation starts with a white sheet of paper. Even for existing software.

ce: Do you have some kind of method(s) for yourself to reflect on the exploration part of the design process? With reflect I mean looking back and see (or document) where you could improve/change your existing method/approach in exploring the design space.

ps: I have a friend who is a traditional (building) architect. He says: ‘no architect has build anything significant before his 40th birthday.’ I am only 37 right now.

With every project I learn more. There is no repetition in solutions. Methods evolve constantly, and new ones are born. One method I use is to reflect on my profession and recent experiences while cooking dinner.

ce: What is your advise to students to what they should focus on in education and/or profession?

ps: They should focus on diversity in their education.

Whatever it is that they are studying today, it will only give them a good grounding in 30% of the array of skills that they will need for the job. They will have to go out and increase that ratio by studying other topics.

ce: Do you think there will be any major changes in the field of HCI in the next years?

ps: 99,99% of the software out there never had the benefit of having an interaction architect on the team.

They are awful and inefficient to use.

99,99% of serious websites out there have professional graphics design but show no sign of involvement of an interaction architect.

They frustrate and repel visitors.

The major change will be that interaction architecture will become a mainstream profession. The software and web companies are gradually increasing the demand for interaction architects, driven by business demands.

But there needs to be a sharp increase of interaction architects. At this moment you can estimate in Europe the number of them in your area by dividing the number of inhabitants by 100.000.

We need more students who move into our field, and learn with us on the job until they have become masters themselves.


proprietary, reflection and the craftsman

To explore the design space and to gain understanding of the domain, a basic condition is some kind of process to do this. When reading Interaction Design beyond human–computer interaction [1] the authors talked about iteration, design models, the focus on the user and so on.

But beside this theoretical ‘how should it be’ view there is a more practice perspective on the design and exploration process in itself when focusing especially on companies dealing with interaction design. Designing seems to me—a person who never came very much in touch with design by now—an ever changing action.

The book from Löwgren and Stolterman [2] expresses this kind of thinking in a more scientific way. In detail they basically discuss and describe the reflection in interaction design and, which is partly based on the earlier published and announced material on the Reflective Designer by Schön [3][4][5] in the 1980’s, but they extend this perspective and take a deeper look at the entire environment of the designer and try to describe the thoughtful interaction designer.

According to the authors, a designer should reflect on the digital artefacts she wants to create, on the entire design process and on its own person which includes the own behaviour, thoughts and views as well. This interpretation seems to be more suitable and realistic when looking at current practice in interaction design companies.

Taking our example here with man + machine interface works, they have proprietary processes which probably may differ from the theoretical models described in the known literature. As Peter Sikking told us, the reason for this is founded in the ever proceeding process of gaining knowledge, experience and of reflecting on the own work, even if latter is done indirectly and the the designer is not aware of this.

Here we can see parallels to the approaches described by Löwgren and Stolterman and it can be concluded that the reflection might be one of the reasons why companies like m+mi works have proprietary processes as the proceeding in a project becomes some kind of unpredictable due to the changes caused by reflections. This perspective on interaction design also might show up that interactive design is more like work done by a craftsman.

Jones [6] already writes about the craftsman work according to design in general, but although nowadays designing is often a project with various involved stakeholders,in some cases it still seems to be truly similar to the craftsman’s work. The companies and design teams use proprietary processes which are based on the experience of the (head) designer itself.

This is comparable with the knowledge gaining process evolved through the entire life of a craftsman, which is also a proprietary process and makes it difficult for other external people to join the craftsman’s team or to learn from her.

The conclusion for me is that the process of design or interaction design is not something which you can express in a few words or generalise for a couple of situations. In fact it is a unique thing and it is not possible and probably will never be possible to put, or better force, design into general standardised process model or when seen from the other perspective: process models for design activities can only be vague and superficial regarding to the entire process. On the other side, loose frameworks could help and guide the designer to make the right decisions and follow the intended path.

bridging the gap

Although interaction designers or architects always have to know something about the available technology and especially how to use this technology, they normally do not have detailed or at least not current up to date knowledge. But they need this knowledge to narrow down the available solutions and to be aware of all their advantages and disadvantages.

As I can interpret from the interview with Peter Sikking, most of the architect’s works deals with the negotiation between the customer or user and the development team. And here we see that he benefits from the technological knowledge he gained in the earlier years of his career. It can be assumed that his business would not been that successful if he would not have it.

But this not only a negotiation role, more or less the designer has to bridge the gap between those both extrema and fill it with her own ideas and creativity and make both perspectives compatible to each other. These finding seems to be coherent with the theoretical ideas on interaction design I read before, but in the case of the considered company the architect plays a more overarching role than usual.

That is maybe already expressed by the word architect, this nomination has in our current known corporate hierarchies a more important significance than the position of a designer. In my personal opinion architect describes a position which is more relevant to constructing something and developing a product than being creative and develop different solutions for a digital artefact [2]. So, referring to Löwgren an architect could be more at home on the engineering perspective of design [7].

But on the other hand, as I mentioned before, the word architect is related to the verb to arch and in this case it can be used in a different sense to express the special meaning of the gap between developers (in the sense of product implementation) and the customer and users.

In Peter Sikking’s company m+mi works the head of the company, resident in the HCI services, is a person or team which grew up in the broad field of interaction design. This fact is for example different to other enterprises with their own HCI department or designers.

Those are not necessarily people originated in the interaction design field and additionally, they usually do not have the power to of influence in those companies. The dominating professions are business administrators, engineers or even developers, but only sometimes designers.


As described in the introductory part of this essay, I want to focus more or less on the design space exploration part of an in interaction designer and I want to know how this is practised beyond literature. The last two paragraphs were intended to stabilise the now following explanation and remarks on the interview.

According to the answers Peter Sikking gave me, there was one point which remembered me on the Löwgren and Stolterman book [2], that was the part dealing with the vision. But after thinking a bit more detailed and going back to the literature again, then I realised that the word vision is used in two different contexts.

Löwgren and Stolterman define vision as one of the first ideas and thoughts a designer has when being confronted with a new instruction respectively a new job. Depending on the experience of the designer, the vision emerges quite early and more detailed or later in the process (page 17).

This vision or some different visions change and become more detailed through the evolving process. The authors define two more abstraction levels of the design process. These are the operative image and the specification.

I am aware of the fact that these levels of abstraction are outcomes of a very theoretical point of view, but it also shows the differences between nominations in education and research and in practised interaction design.

In the latter, vision in our example here, seems to be partly the combination of all three abstraction levels and practitioners have one activity which is split up by scientists into many different parts. Although in this case I do not have enough information to prove it but that is what I would expect.

When discussing reflection in the first paragraph of this chapter, it was meant more generally and in the way Löwgren and Stolterman respectively Schön would talk about reflection or thoughtful design.

In the design and product development process of m+mi works we have a different sort of reflection but in my opinion it is still related to this. When asking Peter Sikking about problems in the data and information gathering procedure, he answers that all active participants provide a continuous feedback loop to each other.

For this reason it is possible to counteract against emerging problems very early in the process and resolve any inconstancies or misunderstandings immediately.

And to be successful in those feedback sessions all the participants have to be aware of their own objectives and if problems occur they have to think about why those problems have been occurred, so that they are able to avoid those or similar ones in future projects. Those feedback session are a good basis to achieve reflection on the entire process of interaction design.

When asking Mr Sikking directly about reflection in process, he gave me, beside the fact that he is reflecting while cooking dinner, a significant answer which emphasises the unique character of each design project. No project is equal to any other previously done work.

This makes it necessary to develop some kind of meta methods which enable the designer to use his knowledge for every unique new project. But this again requires reflection and documentation during a running project and at the end of them. Only thereby it is possible to be a successful designer who truly broadens her horizon with every project.

One aspect which is particular emphasised by my interview partner is his so called Zen Moment of which I did not heard about yet. Do understand this phrase I was looking for some kind of definition which makes it more clear to me and this part was quite difficult though it is used very often as a phrase and many people do not really know what it actually means.

‘Zen is a branch of Mahayana Buddhism which strongly emphasises the practice of moment–by–moment awareness and of “seeing deeply into the nature of things” by direct experience.’

The Moment of Zen itself is a moment of reflection on a particular thing which inspires the persons who shares it. It is also used as a description and synonym for enlightenment and insight in a particular situation. Even if religion and mystic has most of the time nothing to do with interaction design, it can be seen as a metaphor or analogy for the reflective process in interaction design.

Most of the people in the practical ID sector would never come up with thinking on reflection during their work, instead they use circumscriptions like the Moment of Zen to express such experiences. In the case of Peter Sikking this moment is the time where he finds the essential solution for a particular problem.

Regarding to the previous paragraph in this chapter mentioned the engineering design perspective, it becomes more clear on this point here. According to him, the process of exploring the design space is finished when the essential solution has been found.

Based on the theoretical knowledge gained by now, I have to say that this way of thinking belongs more to the engineering perspective of design, where the designer is satisfied with one good enough solution and will stop developing design alternatives after finding this.

During the interview I was especially interested in problems which may occur within the exploration phase and also the restrictions with which the designers and architects are confronted.

When Mr Sikking mentioned the Moment of Zen, he also said something about internal and external restrictions, which is an interesting classification and this maybe says that we should not take the Moment of Zen interpretation very literally.

External restrictions are all those restrictions over the designer has no or only a little influence, these are for example time and budget constraints but also problems occurring during the process like changing conditions or requirements which do not allow any further proceedings.

With internal he did not mean any company or team internal restrictions or problems rather than the events and actions happen in the designer or design team minds. Those internal restrictions signalling the designer that something has to be stopped at this point or that something is not possible like the way it is done or will be done.

For me observing this kind of thinking is rather new, normally most of the designers or architects are aware of restrictions but those are usually the external ones.

In the case of Peter Sikking one of this internal restrictions is the Moment of Zen and beside the argumentation before, this moment does not necessarily mean that the essential solution has been found, more it says something about that the designer thinks about her own ideas and work which is, according to Löwgren and Stolterman [2], necessary and required to be a thoughtful interaction designer.

When we discussed the exploration phase of designing in class we were also talking about exploring under different starting circumstances. We asked the question if it might be easier to start a project from almost zero or if it is easier to be thrown directly into action. When you start a project from the beginning than you have all the freedom and much fewer restrictions than else.

But is this really better than being thrown into a world of constraints and conditions? The result from our discussion was that having constraints and and environmental conditions is more helpful to the designers to start with and starting with nothing can be even more difficult as there is too much room for interpretation.

That was the reason why I asked Peter Sikking for this situational problem. He agreed with our belief that regardless of starting from the beginning or in in the middle of a project you always have to start from a zero point, considered from the designer’s perspective, only the starting conditions are different.


Even it has been quite difficult to get a deeper understanding of an interaction designer’s respectively architect’s work from those few questions and answers, they showed to me some basic methodology in their everyday work.

Although it would have been better to have to some questions answered more extensively and detailed and against the background of having not much experience in the field of interaction by myself, but I am now able to balance theoretical ID and practical ID at least a bit.

And I can also say that the theoretical aspects can be regained in today’s interaction design companies. But I am not that satisfied with the information gained through a single interview, I would like to retrieve more information on the entire design and development process, this should also include practical experience.

I also should ask myself if I asked the ‘correct’ questions, I mean this in the sense of suitable questions which deliver valuable information for the main topic. My intended main topic was the design space exploration, but the insights I got from this were not those which I expected before, so I have to ask myself again if just the expectations have just been too high or the the questions not suitable enough.

I want to conclude the design space exploration with one sentence: How good or bad a design solution will be depends very much on the designer’s experience and the quality of the first vision.


[1] J. Preece, Y. Rogers and H. Sharp: Interaction Design beyond human–computer interaction, John Wiley & Sons, 2002

[2] J. Löwgren and E. Stolterman: Thoughtful Interaction Design, MIT Press, 2005

[3] D.A. Schön: The Reflective Practitioner, Basic Books, 1983

[4] D.A. Schön: Education the Reflective Practitioner, J.B. Wiley, 1990

[5] T. Winograd: Bringing design to software: Chapter 9 Reflective Conversation with Materials An interview with Donald Schön by John Bennett, Addison Wesley, 1996

[6] J.C. Jones: Design methods: seeds of human futures, John Wiley & Sons, 1981

[7] J. Löwgren: Applying design to software development, Proceedings of DISD ’95, Symposium on Designing Interactive Systems: Processes, Practices, Methods & Techniques. Univ. of Michigan, Ann Arbor, Michigan, August 23–25 1995, p87–95.