Simon Milfred > Portfolio

User Experience Design

As a user experience designer I subscribe to the school of pragmatic design thinking. "Design thinking" - a very popular buzzword these days - does not mean anything more than "design" has meant to practicing designers for ages. It simply means, that I am context- and user-centric in my approach to design problems, and that I empathize with the users at hand and frame the design situation by analytically defining where the users' problems exist in the world. This allows me to ideate on a strong foundation of knowledge, and as I design my solution to improve upon the situation, I make sure to pre- and prototype my product and test it with the users, so that the best possible solution may be implemented. In short, all the term "design thinking" says is that design is more than simply prettyfying things.

I may be biased by my education, but I value keeping the users included during as much of the process as possible. However, it is also of great importance to me to be efficient and swift in my execution of my work to fit in a Lean or Agile work environment. Luckily, user inclusion does not mean weekly workshops and does not always have to take that form. To me, user experience design and design thinking are very much about processes, and as every design case is unique, so is every design process and their means to execute on them - and I take much pride in my adaptability.

The itereative wheel of design thinking

Let me exemplify this through the concrete case of "Faldisnak", which clearly shows the iterative nature of a particular design process: Empathizing with the users, defining the situation, ideating and prototyping, looping back to re-empathise with the users based on the obtained findings, re-ideating and prototyping and finaly developing the solution (which, in this particular case, was still a prototype, just with much higher fidelity). Feel free to skip to the summary, if your are here for the quick overview.

Faldisnak: A User-Centered Design Process

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.

Illustration of the Faldisnak process

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.

Simon Milfred looking at probe results

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.

Train station

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.

Sketch of the present scenario

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.

Sketch of screen with a big, red button in front of it

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.

The making of a prototype Prototype button in action

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.

A series of challenge cards

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.

Three workshop participants discussing app-visuals and rethorics

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.

Bare bones app design Bare bones app design Bare bones app 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.

The avatar standing ready to jump out. The avatar standing with passengers.

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.

Users trying the experience prototype

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.

An Emphasis on User Empathizing

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).

Image from 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

Understanding the users' needs through empathizing allows for defining the design problems, and defining the design problems allows for making the right thing instead of just a thing. However, when I define design problems, I don't do it by defining problems. That's not what it's about. Defining problems in design is moreso a framing of the situation at hand. For example, if I want to design something to blind people, I can easily state the problem to be "they are blind", but that does not help neither them nor me. Instead by framing a situation - the design problem - I might pick up specific areas of their lives which can be improved upon, which helps me design something which brings much more value to their lives.

Prototyping and Testing

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.

Gif of the Omni prototype

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.

Gif of Tale of Omni

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?

Final step in the process - whether I am designing a full on product or just a feature - is of course implementation. This does not mean it cannot be iterated further upon, but it should mean that the product or feature is in a usable state. A lot of products - especially digital products - are developed further upons release. New features to keep them on top of the market or redesigns to fit the latest design trends, for example.

And as the implementation concludes the design process (ish), this concludes my run-down of user experience design. Hope you learned something about designing or at the very least about me as a user experience designer.

Check out my project bank for more examples of my user experience work.

Visual Communication

I have always been fascinated with visual communication and have always been a visual thinker. Visual communication is of course a broad subject, but I can honestly say, that I love all its disciplines and perform a lot of them with high professionalism and great results. I have done pencil drawing since I was very young, painted a little, and I don't even remember how young I was, when I started making graphics on the computer, but I know that it was a good while before I started making video games, which was when I was about 11 years old. Below are a couple examples of my art from 2012 to 2016 (left to right). You can check out a few more of my works on my Behance.

Pencil drawing from 2012 Inktense drawing from 2015 Digital illustration from 2016

As I became more and more experienced with the static visual communication forms, I also became interested in communication in motion: Animation, video editing and film making. This of course went hand-in-hand with my game developing, as I needed to make animations for my games as well. I ran the YouTube channel Bless Hay Gaming from 2013 to 2018, where I taught game development in the software GameMaker:Studio. I did all the planning, recording, branding and editing by myself. Now Bless Hay Gaming has moved away from YouTube and onto its own domain.

Skeletal animation work made for the app "Sepiida Water".

A commercial I animated and edited for the FOSIA case competition in Aarhus.

A short film I made during my course in visual media production under Richard Raskin. I did some of the writing, directing, filming and editing.

An example of one of my GameMaker:Studio tutorial series.

From early on I started doing freelance jobs for smaller companies. I started out doing simple logos, posters and other simple, graphical tasks, and as I grew as a graphics designer, I went on to customize typography and to consider things like brands and brand identity.

My design printed on cards My design sewn into one of Ditlev Lommers jackets

Logo design for Ditlev Lommer.

My design printed on cards

Logo and hoodie design for Coding Pirates (GameDev, Aarhus).

I have always been very thorough in my process, making multiple sketches and iterated upon them with the customer to make sure my work fulfilled their needs and wants as well as reflected them and their business - and my focus on the customer and the end user only grew during my Digital Design education.

Logo variant Logo variant The logo variant used by RE:Festival

A couple of the logo suggestions for the RE:Festival, an annual culture festival on Funen, Denmark, which I helped kickstart. The last logo of these was the one used by the festival.

I have worked with a broad array of visual communication areas by now, and while there is always more to learn, I have become quite adept at producing visual content. But one thing is making something pretty and stylish, another is making something fitting. Being a visual communicator is being a visual and multimodal rhetoric: You need to know and understand both the sender of the message as well as the receiver (and of course the message itself), and it is important to have a feeling for kairos, a rhetorical term for "the opportune moment": Timing the communication as well as possible and understanding the rhetorical situation. I do these things well, and I learn the ins and outs of a rhetorical situation fast - and I had rhetorics as my supplementary subject during my bachelor, meaning I have the formal education as well. But I never stop learning.

See the Pen Bouncing Hoptimist by Simon Milfred (@SimonMilfred) on CodePen.

I made this bouncing hoptimist to add some playfulness to a website.

In summary, I am a visual thinker with a broad range of skills, which I use to accomplish astonishing visual communication, and I understand the communicative and rhetorical aspects of this line of work as well. Feel free to reach out, if this particular skillset fits you or your company.

Check out my project bank for more examples of my work concerning visual communication.

Game Design

My maybe greatest passion in life is designing and making games - in particular, though not limited to, video games. It is a passion that has grown steadily in me for the larger half of my lifetime starting as I made my first, small video games in the ripe age of 11.

While my work with games touches upon almost the whole process - designing, programming, making graphics and animations, etc. - I foremost love to do the design work. I enjoy coming up with ideas and concepts, which is also one of the reasons I enjoy participating in game jams, and I thrive in fine-tuning and alter these concepts as a project moves along. Game design presents a lot of varying challenges, and next to nothing gives me as much joy as to think my way around the rising problems and obstacles.

Omni gameplay gif Fall Harvest Season gameplay gif Eagle Eye Emma gameplay compilation gif

My backlog of game and mechanic ideas extends to an amount I am not willing to count, and while it bothers me not to have the time to proceed with each and every idea, often the ideas end up being infused in other projects I am working on. When I come up with a new idea I most often write it down somewhere and build the thing fully mentally, but sometimes I also make a mock-up or prototype to get it out of my system.

NOT a Fan gameplay gif

NOT a Fan is a prototype of a game idea, where the player is taking on the role of a fan (the ventilating kind) trying to pass as a human. The game is partially inspired by the turing test, Octodad and balloon flight games.

My current flagship project is Tale of Omni, a hyper-mediated platforming adventure which developed from a previous game jam entry titled "Omni". It is a large scope project, which will take us many years to finish, but that is time both my team and I am willing to put in. The project started in late 2015, and we are openly sharing a lot of the process on our blog and across social media - especially on Twitter.

Tale of Omni gameplay gif

Other than making games myself, I am also actively trying to help out future generations of game developers. I am producing online tutorials through the alias Bless Hay Gaming (also an alias/hobby company I am developing games under), and I am an active volunteer at the Danish organization Coding Pirates, where I do workshops with children teaching them about technology and games programming as well as facilitate game jams for the kids.

Simon Milfred during a Coding Pirates workshop, this one in England

I have previously been personally mentoring aspiring game developers as well, and I would love to do so again. It is a wonderful journey to follow and guide. I will, however, no longer be doing so for free.

This concludes my segment on game design (and making). I hope you, or someone you know, will have fun playing my games in the future! Check out my games page for more examples of my work concerning game design and development.