Some reflection

Today my supervisor and I talked about the creative process and how I usually do in terms of combining programming work with the design aspect. I remember that when we met, we talked about it and as I did not have much experience I thought that design would come first, and then I would code to make things work. But today we brought this up again and I realized that in practice it does not work like that – ok first I did some design, some visual prototype, but when I started coding, I did not stop working with the design either. It was not like first I do the design and then the code, period! You work with both all the time.




Co-designing workshop

After I was done with the lo-fi prototypes I showed them to my customer, to see what he thinks about it, if he understood the structure, the features, and so on. And also to see if he was satisfied with the outline. And I also gave him a task – draw his vision for the app.

Furthermore he has shown how he works today, the several applications, services he uses today, without any integration. It takes a lot of time to keep all the client files updated. He also stated that many of these applications are too confusing. He considers himself computer literate, but even so he has hard time understanding these platforms.

It became clearer what he wants – a very simple interface where he freely can add information – customized exercises, notes, stats, everything gathered.

It is also important that he can administrate, make changes, whereas the clients only have access to information, without being able to make changes.

That would require both front-end and back-end development, something I am not that familiar with. But he said as long as you can send somehow the info, it is fine – the first thing that came to mind was email function, but he also tends to get carried away.

Finally, he told me about a Facebook group for personal trainers, where some of them expressed frustration concerning the absence of a simple , straight-forward tool.

I wondered if he would be willing to participate in a workshop with other professionals in the area, but he sees it as a risk due to concurrence. However he would eventually bring this up in the Facebook group.





Sketch and Prototype

Now that it is clearer what the application will be like, what functions it will have, I started doing wireframes in an old school way – paper and pen.

So, after the research and brainstorming, we had to discard Volt app concept – it is not created for the trainers, but instead for the clients – that could even lead to an equivocal feeling that the trainer is expendable and replaceable by an app that is much cheaper.

That’s not what we are looking for – our goal is to help the trainers, make their work more efficient.

The first step was to make a wireframe that shows the main functions, and interactions – what kind of feedback you are expected to get for every action. It is not a representation of the graphic interface, or design per se, but the representation of the application logic.

The wireframe also works as starting point for making lo-fi and hi-fi prototypes – once you know what functions and hierarchies they will have, it becomes easier to place them in a graphic context.

I sketched by hand (with pen, paper, and pro markers) frame by frame, and after that, I made new prototypes with Photoshop – still lo-fi but not as lo-fi as drawing with pencil and paper.


Lo-fi with Photoshop


Brainstorm and research

After discussing the project task,   we met and had a brainstorming session – we went through functions that he wanted for the application. In this session, he explained first the problematique – within his branch there isn’t a all-encompassing app, where the personal trainer can use to both enter information about the client, screening test results and enter a workout plan that can be easily mailed to the client. So we went through some of the existing apps and platforms, so he could show the flaws. So we together came up with some ideas on how our app could look like in terms of functionality and user-friendliness. After this meeting, I looked for other examples, similar applications, in order to see what has been done, and what needs to be done. Most of these apps are inflexible, since the user can only enter an exercise that is already in the app database – what if the trainer wants to enter a completely customized exercise? I actually found ONE app where the user can enter customized exercises, but after the trial period, you have to pay a monthly fee or something. It is called Volt and is niched for sports, and athletes, the same niche as my customer works within. However the app is directly to the trainers’ clients, whereas a work tool for the trainer is what we are looking for.

So after this session, it became clearer what our application would be like – which functions it would have, and how it would address the aforementioned issues.





First days at Tapper Geist AB

My first days as an intern were somewhat overwhelming. I was not quite sure if I would be achieving anything usable. Let’s just say that my self-confidence level was pretty low. As I would be working basically on my own, since I got my own project and customer, I was feeling intimidated. My supervisor would help whenever necessary, of course, but when it comes to the coding part, there was nothing she could do, since her expertise is the design part.

From the very beginning I developed a close contact to my customer, IFC. We discussed the project, what was expected from me and so on. The customer was always understanding that the focus is the learning process, rather than developing a “ready to ship” product.

We also had to establish some delimitations, due to lack of time and resource – initially there was some wish to develop an iPhone app. But I made it clear that such type of app would require much more time, and as I am the only one programming, it is not realistic to develop an Iphone app during this time, but of course this wish could be pursued once the internship is over.



Final Essay – Ambiguous about ambiguity


Ambiguity (noun am·bi·gu·i·ty \ˌam-bə-ˈgyü-ə-tē\)

 (…) the fact of something having more than one possible meaning and therefore possibly causing confusion” (Cambridge dictionary –Online)

Given the definition above, one can wonder if ambiguity has any place within Interaction Design. As Gaver et al. (2003:233) points out, ambiguity is usually something undesirable – usefulness and usability are considered two imperatives to Human Computer Interaction community – how could an interface be any useful if the information it sends is confusing?

The authors claim, however, that ambiguity can actually be seen as an opportunity rather than merely a design problem. Their argument is that, while ambiguity can be confusing and lead to frustration, it can also be mysterious and exciting. Moreover it leads to increased personal relationships with the object, because the user will make a huge effort in trying to decipher it (Gaver et al, 2003:233).

During our fourth module we were introduced to this concept, and we were supposed to work with it, or at least consider it when sketching and building the prototype. I have never thought that ambiguity could be desirable or something to strive after.

Understanding ambiguity 

As aforementioned, Gaver et al advocate ambiguity as a way to enhance interaction with an object by impelling people to engage themselves in trying to grasp the design (2003:233). The point is that they will put so much energy in trying to figure out how the object works and the concept behind it, that it will lead to deeper relationship between the user and the artifact (ibid).

When it comes to ambiguity I have always associated it with confusing information the artifact conveys. However, Gaver et al. expand my understanding. There are two other types of ambiguity besides ambiguity of information, namely contextual and relational ambiguities.

In this session, I will briefly explain these three types of ambiguity.

Ambiguity of Information

Here the ambiguity arises in the manner that information is presented to the user by the artifact. It can be in form of unspecific GPS coordinates given to people playing a game – for instance scavenger hunting (not exactly the example given by the authors) – it will be more challenging to those playing it, and it will evoke cooperation between the players in the same “team” in order to decipher the game fuzzy hints and imprecise coordinates (ibid:236).

Ambiguity of Context

Ambiguity is not only about unclear information you get from an artifact. It can also be an artifact that is supposed to be used in a certain way, but the designer assigns a completely unanticipated usage to it, which leads to user’s puzzlement and why not amusement? The example given by the authors is a sculpture, Duchamp’s Fountain, which was actually used as a urinal. The interpretations are conflicting – is it art or is it where you fulfill your physiological necessities (Gaver et al, 2003:236)?

And finally, ambiguity of relationship, which arises from the viewer’s personal relationship with the artifact (ibid:237). One example is the Waterbed (see Larsen, 2013:60pp), where someone simulates intercourse , something very private, and the bed makes different sounds depending on the pressure you put on it – it was done as an art installation, and it gives a new role to the viewer, who in this case becomes more than a viewer, and becomes a voyeur.

The authors go on to explain how you can enhance ambiguity of information, context and relationship (Gaver et al, 2003:237pp). They believe that enhancing ambiguity will make the artifact system seem more attractive and mysterious and it will make people want to join in the work of making sense of an artifact system and its context (ibid:237). They do however show under which circumstances this might work – it can be by using imprecise representations to emphasize uncertainty, e.g. showing blurry graphics, or by adding inconsistent functions to a given artifact or by offering unfamiliar roles that can lead to increased imagination.

They conclude their article by considering ambiguity as potentially positive that can lead to crafting interactive designs enhancing personal relation to the artifact and that stimulates the user’s thinking process (ibid:240).

You can even see a link between this idea and Fokkinga and Desmet’s text on enriching user experiences with negative emotions (2013). For these authors, designers can enrich user experiences by purposefully involving negative emotions under certain circumstances – they show how negative emotions can make a product experience richer and enjoyable. They present to us ten experience qualities that combine three steps in how to turn something negative into positive. For that to happen, the designer will decide 1) which negative emotion will be evoked, 2) how and when this emotion is best stimulated and 3) which protective frame is most appropriate to use and in what way it is applied. In other words, it is about how a designer will trigger a negative emotion in the user and which mechanisms will be offered in order to turn this negative emotion into something positive (Fokkinga & Desmet, 2013).

The clearest similarity we can see in these two texts is when Fokkinga and Desmet explain the challenging attribute, which entails an experience that is frustrating yet engaging problem that people are determined to solve. As the aforementioned example on ambiguity of information (scavenger hunt), the user can experience it as frustrating – unclear coordinates and fuzzy hints, and feels a dissatisfaction from dealing with something so hard and confusing. But at the same time, they become more focused – they have a goal to achieve, so in order to succeed, they engage a lot in the interaction with the artifact, trying to figure its system out (2013:27).

Ambiguity as an interaction quality has probably gained ground within HCI due to a shift from user-driven design, in which the user’s needs are central in product and service development and from technology- driven design that implies applying newly developed and invented technology (Maeng et al, 2012:449) to a interaction-driven design, which aims at exploring product possibilities and interaction attributes. Consumers were, according to the authors, attracted to functional useful products that fulfill their needs, but today you do not see many functional discrepancies among the products in the market, while the technology used by the companies became increasingly homogeneous (ibid:448). So how is a company supposed to attract consumers if it does not offer anything that lead to competitive advantage in relation to other companies? By focusing on user experience? That’s right, and where interaction-driven design comes in to play an increasingly central role within HCI and product development.

Designing for ambiguity in practice – The Magic Hairbrush

Given this brief theoretical account, it is easier to explain our design process having ambiguity in mind.

In previous modules, we never flirted directly with the idea of creating something susceptible to several possible interpretations or unconventional functionalities – we have always strived after clear and user-friendly designs, the usual goals in HCI, as it has been mentioned before. In hindsight I do however notice a shift from user-driven to a more interaction-driven design in our work – now the focus is moving from the user’s needs and desires to experiences, how the user interacts with an artifact and perceives the experience. Our projects became gradually more abstract and conceptual, susceptible to different interpretations and, therefore, less concrete.

Module four was a novelty for us – ambiguity from being considered unintentional becomes a conscious choice. The theme of this module was body in everyday movement. We are supposed to turn something mundane into a richer experience, with the help of Arduino, sensors and sound (using Ableton). And for that, we were introduced to three concepts: ambiguity, tightness – ok, this one was not new, we read Wensveen et al.’s text (2004) in module – and openness. For us, tightness and openness were something easier to achieve. But ambiguity? How is a trivial activity supposed to be ambiguous?

After reading Gaver et al’s text (2003), it became clear to us how we would explore ambiguity – We chose to work with only one type of ambiguity, namely ambiguity of information. Honestly, we were not sure how to achieve it; we only set it as a goal.

The everyday movement we decided to work with was brushing hair – a movement that is one-directional, repetitive and usually slow-paced. After considering all the possibilities, we decided to use two photocell sensors, mostly because they are cheap and yet versatile. They would be used in two different places among the bristles – one in the middle and other on a corner. The idea behind it was that they would capture different data – the light is distributed unevenly along and across the hairbrush due to angle variation. When you use the brush, you will get different sounds and this design is ambiguous because you are not sure what the output will be, what kind of sound you will get. Another variable that makes the design more ambiguous and that we discovered during our sketching sessions is the user’s hair color – my hair is almost pitch black, whereas my partner has a lighter hair color, and imagine our amusement when we got different results!

Despite the design’s ambiguity, it has a certain level of comprehensibility – something will happen when you brush your hair, and once you start brushing, you will soon figure out that sound will be produced, and the way you brush your hair will have an impact on the output, but you do not know HOW.

We achieved the goal to make the design somewhat ambiguous. We could have explored other ways to enhance ambiguity, but given the time constraint we have decided to keep it simpler.

Did the ambiguity of the design lead to enriched experience? I cannot say that it turned something mundane into pure excitement, but definitely more fun to brush your hair and having different sounds as feedback. However, you tend to get annoyed after a while, i.e. the brush coolness and novelness are short-lived.

Conclusion and Final Reflection

After reading the text and finishing the module 4, my perception of ambiguity in design has not changed much – from completely ignoring its existence within the realm of HCI to coming to terms with its use, however in a very limited extent and scope. This can be noticed when you read the examples given by Gaver et al (2003). None of their examples serves to a real purpose other than shocking or/and entertaining people.

I think that there are some circumstances under which ambiguity can be considered positive – usually it involves experimental or artistic designs, toys and games, since they do not have any function other than entertainment and contemplation and in some cases enticement of one’s imagination and thinking process.

When it comes to interaction design in terms of making our lives easier and facilitating the interaction between people and machine, the use of ambiguity is inappropriate, since it slows down the understanding on how things work. As an example we can take “smart” home appliances, i.e. in the realm of Internet of Things – they are created in order to better serve our needs, by minimizing the time and energy spent on mundane activities, so we can focus on productive, meaningful activities instead.

I might be considered old-fashioned, but my goal as interaction designer is to make our lives easier and help those who need it the most. My focus is on user-driven design with some interesting twist that does not drag down its functionality. And I still think that ambiguity is usually an excuse for bad design. There are, in my humble opinion, better interaction attributes to focus on, such as tightness, since it leads to perceived couplings between action and reaction that are inherent in mechanical products and that electronic products often lack (Wensveen et al., 2004), or in other words, the artifact becomes a natural extension of our bodies.


Cambridge Dictionary. Ambiguity. Available on Last accessed on 4 November, 2016.

Fokkinga, S.F. and Desmet, P.M.A.(2013).’Ten ways to design for disgust, sadness, and other enjoyments: A design approach to enrich product experiences with negative emotions’. International Journal of Design,7(1), 19-36

Gaver, W et al. (2003) Ambiguity as a Resource for Design. Florida: CHI

Larsen, H (2015)Tangible participation – Engaging designs and design engagements in pedagogical praxes [dissertation]. Available on , p. 54-67. Last accessed on 4th November 2016.

Maeng, S. et al.(2012) ‘Interaction-driven design: A New Approach for Interactive Product Development’. DIS, 2012, June 11-15., Newcastle, UK.

Wensveen, S et al.(2004) ‘Interaction frogger: A design framework to couple action and function through feedback and feedforward’, DIS, 2004 , August, Cambridge, MA. USA.


Show and tell

Today we had our presentation on the fourth and final course module, and we have seen very interesting concepts.

When it comes to our work, people seemed to like it , they found it interesting – it was a big plus that no wires could be seen, so they thought it was very well assembled. Their feedbacks made us feel proud, after so much struggle with building the prototype and connecting with Ableton. Our teacher also liked the fact that we used the photocell sensors in two different spots  in the brush, because they could collect unequal data. Furthermore, he commented on the design tightness – the hairbrush felt tight not only in terms of immediateness – you use the brush and get an output – but also in terms of closeness, i.e. the closer it gets to the hair, the more intense  the sound gets; and modality , i.e. the sound will change depending on how you brush your hair.

This finding was actually very interesting for us because we used the same type of sensors and still we got differential results – before implementing them, we did not think about an important variable – angle. As the angle varies along and across the brush, you will get uneven distribution of light.

Summarising, we received a very good feedback and all the struggle we had to conceptualise and execute the design was worth it.

When it comes to other groups, there were also some interesting design concepts. My favourite one was developed by Marcus and Emil – a paintbrush that sounds differently depending on how you stroke – they played with bass and treble. Something remarkable about this group is that their design was based on research – before they started sketching the design, they read a lot about how paintbrush can be used.

The research part we have sort of skipped, and now in hindsight, we could have gone deeper with our design. I suppose it was the time constraint that made us go straight to brainstorming and sketching.

Many of the other groups used light sensors as well, in different ways – which made me ponder – how incredible and versatile a light sensor can be, and yet so simple!

Concerning our own presentation, i.e. the show ‘n’ tell session, I was rather satisfied – we managed to describe what we have done, why and how, and explained the concept  in terms of ambiguity, tightness and openness. We have also brought up technical issues.

This module was very challenging – we were newbies when it comes to Ableton, we struggled a lot with playing with sound, and sketching something that works – technical and aesthetically and that is interesting at the same time – how to make something trivial , unremarkable into something more exciting?

But in the end of the day, every minute of frustration  was worth- we learnt a lot, not only how to use Ableton and avoid short circuits, but also how a ideating, conceptualisation, sketching process works. Additionally we succeeded in turning something dull, boring into something interesting.