Faldisnak was a project I did as part of the design group Primeo during my bachelor in Digital Design. Unlike other study projects, this product would be presented and showcased at an expo, where it would be judged by the likes of Capnova (same expo that kickstarted Frameo, just to give a sense of the possibilites we were facing). This meant to me, that I really wanted to make a viable product, rather than simply experiment with technology, which a lot of my previous study projects had come down to.

The name of the project is derived from the Danish sentence "fald i snak" (though with spacing removed) which translates to "fall into conversation". Our project is documented in Danish on our design blog.

Faldisnak is a great illustration of how continuos user inclusion can shape a project to become something particular. The vision of the project was to design a tool, which allows willing users to start conversations with strangers. This could of course be grounded in various reasons stretching from networking to social anxiety, but the overall goal was to break the conventional social silence which looms over the public spaces of Denmark. The project ended with a prototype application for Android which can be downloaded from Play Store.

Note that the Faldisnak application is considered a prototype and not a fully functional and finished product.

The background behind the project and the target user group - people seeking social encounters with strangers - was simple: We were tasked with making a design for a minority group, and after sending out probe kits, analyzing the data and brainstorming we agreed, that it was a more interesting take to design for people seeking out social encounters rather than for the more traditional minority groups like immigrants or people with a handicap. Furthermore we wanted to avoid looking at minorities as wretches.

Empathizing with the Users (1)

The target user group started out being based in mere gut feelings and personal experiences, and we of course needed to interact with the users to flesh out and verify their needs. We did this through what we call experience learning. This is simply a self-coined term, which means that we tried the discomfort on our own bodies first. We all went out onto the streets and stores of Denmark, where we then tried to initiate conversations with strangers. Our only rule was not to start out explaining the underlying reasoning behind the conversations since that would be an all too easy cop-out. As an example one of my conversations started in a grocery store, where I began the conversation by asking for inspiration for dinner. I ended up learning much from the conversation - oh, including a new chicken-based dish.

After each of our conversations we came clean with our reasonings and transformed the conversations into interviews. We did this to learn how other people feel about conversating with strangers, to get to know our potential users. We made sure to note down their points, and we summarized these points into the generic statement, that people generally like to be approached by strangers for a little conversation, though only if they are not in the middle of something (like reading a book), and only if the strangers are not drunk or telling their whole life story. This summary was based on an analysis of the data and with it, we also wrote down a series of great points and quotes from the interviews as well as from our learned experiences.

A lot of people were open to more conversation in public, but not when their minds were occupied by other things - and they did not want to listen to life stories or drunks.

Defining the Needs

As a next step towards defining the users' needs we narrowed in on a more specific location: The train station. We chose this location, because it both seemed like an accessible domain, and because it is a space, where people sometimes have to wait for a while, meaning it contains the possibility of conversations to happen. A couple of us went out to the local train station and observed for some time, writing down notes of everything we saw happen.

We used our observations to sketch out a scenario of the present to inform our design. We took notice of the potential of an intervention and what to take into consideration when intervening. For example we found that audio was best left out of our design, as espically the train station (but also many other public spaces) already can be quite noisy, and we did not want our solution to add to the noise or to be affected by it. In our sketch of the scenario we made sure to color code people on the train station, so that we could distinguish between potential conversationists and others.

Based in the earlier learned experiences and our observation study, we defined the need for short conversations while waiting for the train to arrive, but also the need for an excuse for such conversations: People need some reason to talk to make it okay.

People need an excuse to initiate conversation. A simple excuse goes a long way, when it comes to conversations.

Now it was time to take this problem definition, and find a way to improve upon it - a way to give people an excuse to start conversations.

Ideation and Prototyping an Explosive Conversation Starter (1)

Our ideation started with a sketching session. For five minutes we drew as many domain-related things on post-its as possible. This was followed by a randomized combination of drawings to spark unique ideas, which in turn was followed by a more generic brainstorm and discussion. While multiple wild ideas were up for discussion, both projections on the train platforms as well as small mini-adventures, we decided on a less-is-more approach and chose to develop a colorful screen with a big button in front of it. The idea was to lure in people to press the button by making it stand out, and then the button would generate three challenges on the big screen: An easy task (bronze, 1 point), a medium task (silver, 2 points) and a hard task (gold, 3 points) - all tasks being something to do during a conversation with a stranger. The participant now had a fun, little excuse to strike up a conversation. Note that the below sketch is a exaggerated conceptualization, not exactly how we wanted it to look.

We decided to prototype our idea in two parts. First we wanted to make the button to test, if people would actually walk up an press it, and secondly we wished to test the challenges. To test the button we made a non-functional button and placed it on a platform at the train station. It was painted and had wires to help fake that it was functional.

To test the challenges, we made a series of challenge cards written on blank playing cards with color-coded backs to simulate the bronze, silver and gold variants. One of us then walked around the train station and asked people to try them out. Each trial was followed by an interview.

It was simple work but we learned a lot from the two prototypes. Mainly that participants found challenges to be a fun acticity, as well as which challenges were considered too awkward for participants to perform, but also that the big, physical solution was not the way forward. People did not press it. Some even called the train administration thinking it was a bomb. Ups. Also the participants of the card prototype felt on display, when a lot of people were around as they received their objective, and having them standing by a huge screen would not help on that.

The users don't want too much attention drawn to them, so the product needs to be discrete and not look like a bomb.

After pondering on the situation for a while, we chose to take the challenge aspect of our current idea and move it to another, more private medium - the mobile phone.

Empathizing with the Users (2)

Design processes are iterative, and moving to another medium meant that we had to re-empathize with the users, now in terms of phone features. This is not to say that what we already knew were useless - we simply needed to account for phone as well. Because of this we held a user-workshop where we looked into how our target users are using their phones, which kinds of notifications they like to receive and which they do not, what data they are comfortable sharing with an app, which visual and rhetorical direction the app should take and much more. Instead of simply interviewing we gathered the data through various excersizes.

The workshop taught us a lot about smartphone usage, and it especially informed the playful look the app ended up having. We continued working without audio, as the user would not want to put attention onto themselves, and made it a priority to respect the users and use as little data from the phone as possible. The app should be able to challenge the users, and the users should be able to record their progress, but everything should be done in a simple, private and playful manner.

Ideation and Prototyping a Conversation Starter (2)

Next phase was once again ideation. We ideated upon the content of the app as well as the branding and communicative aspects. In terms of content we started out with the bare bones, which we then integrated within the later developed design.

In terms of communicating the content, we developed a "world" for the app in a comic book-like style. Building on the metaphor of "jumping out into it" we used a plane as our setting and a James Bond inspired character as our avatar for the user. To get his or her challenges, the user (as the avatar) has to jump out of the plane, and succesful conversations would be stored as passengers on the plane.

Next step on our agenda was testing our new concept interface, and we did this through an experience prototype: A low-fidelity cardboard version of our app, where we could slide the screens depending on our testers' inputs. We tested the product across multiple rounds with users of different age groups (going from 10 to 60), and we received a lot of great feedback. I am sincerely sorry I don't have a better picture of the prototype than the ones below, as it worked quite well.

Developing the Solution

Finally it was time for us to develop the product, or at least the final prototype. While we had only been asked to make a mock-up or low-fidelity prototype as a proof of concept, we (and especially I) wanted to go all-in and make something resembling a minimum viable product. As I was the only one on the team capable of programming an app and do animations, a lot of that work was on my shoulders, but we were succesful and ended up with a highly functional prototype which can be found on the Play Store.

To summarize: The user-centered approach allowed us to develop a product, which empathize with the target users. The Faldisnak app gives the users a playful excuse to start conversations and practice their social nature. The app is silent with the phone in portrait mode so that the users are not attracting unwanted attention, and by approaching the problem as being playful challenges and self-logging, the app allows the user to grow at their own pace.

Of course, as mentioned multiple times by now, the product is not finished. It still needs refinement. One natural move would be to simplify it by splitting the app into two apps: A party app and a personal app. This would streamline both experiences and make each product more focused.

While "user-centered design" and "empathizing with the end user" all sounds fancy and buzzword-y, the general concept is actually quite straightforward: If your target users don't need or want your product, then your product won't succeed and make an income or impact. So instead of making a product and cross your fingers hoping for the best (that is called high risk), you simply find out and develop what the target users actually need. In other words, instead of making a product and go fish for users, you first go find the users, and then you let them inform your choices when designing and developing the product. This of course does not mean you cannot target a specific area or product type.

Various methods has been developed to obtain user insights, and I know quite a few of them. However, what works in any given situation can be highly user dependent and to do great user research you need to know which methods to use and when - and how to tweak them to do the job best. I have used various methods ranging from basic interviews and observations over Bad Ideas 3.0 and Inspiration Card Workshops to homebrewed methods like the Spark method (the image below is from such a Spark workshop).

If you are working in a Lean or Agile environment, you can rest assured that design thinking doesn't get in the way of such setup. It can actually compliment such approaches terrifically. While it is true that it takes time to put together and execute workshops (and to analyze the data to make the informations meaningful), techniques like pretotyping (more on that in a bit), guerilla testing/research and hallway testing/research are made to generate quick results, and while such results are not as in-depth as the data from a user-workshop might be, they can be used to validate or reject design decisions and developments in rapid processes.

Defining Design Problems

One thing I particularly enjoy doing is making prototypes. It is an easy way to test ideas, and more often than not they end up showcasing aspects of the design which would otherwise be left in the dark. Depending on their purpose, prototypes can be more or less detailed and functional. This is most often talked about in terms of fidelity and how horizontal or vertical the prototype is.

Fidelity refers to how closely the prototype resembles the actual product both in looks and functionality. The final app-prototype of the Faldisnak project was a high-fidelity prototype, whereas the fake, physical button as well as the challenge cards were of pretty low-fidelity.

Horizontallity and verticallity is a little different. A horizontal prototype is a prototype to test the product broadly, but most often in a shallow manor. Our cardboard prototype of the Faldisnak app was meant to test the broad experience and was as such very horizontal. Sometimes you instead want to test a specific feature, like we did it with the challenge cards - that's a vertical prototype for you. It's when you test a specific thing in depth.

Neither fidelity, horizontallity nor verticallity are binary matters. Everything is on a scale, and a prototype can be of higher or lower fidelity, or be more or less horizontal or vertical.

When I first made the game Omni as a game jam entry (see image above), it functioned as a low-fidelity and vertical prototype for the still-in-development game Tale of Omni (see image below). I was interested in testing the mechanic of connecting the game window to the camera, and my small Omni prototype provided me with a lot of feedback which 1) validated that the mechanic could work, and 2) informed me which changes needed to be made to it. While the mechanic cannot be seen in the gif below, it is still very much a core part of the game, but other than that the two games (the prototype and the work in progress) are very different indeed - because the prototype was meant to be a deep cut.

Prototypes exist in various forms: Video visualizations, carboard constructs as in the Faldisnak project, programs, sketches, electronics, etc.. I can work with all these things and much more, which makes me highly valuable on a team, as prototypes are a great means of communication and a solid way to move forwards in the process. Being a user experience designer does not necessarily mean that I should be able to do this myself, but I enjoy being able to do this kind of work and lighten the burden from the developers' shoulders.

And as the example of Omni showcases, prototypes does not need to be made late in the process. They can also function as what has been coined by Alberto Savoia as pretotyping: Rapid prototyping to inform whether an idea is even worth pursuing before putting in many hours of work.

Implementation, the End of User Experience Design?