Background
Here we have Nils, a 28 year old management consultant at Ernst & Young (which is surprisingly enough also situated in Jakobsberg). He lives just outside of Karlberg with his girlfriend Louise in their newly bought apartment. Both of them met at work and therefore share the same daily commute, except during Tuesdays and Fridays which is when Nils tends to wake up earlier for an early game of squash at the sport center Wasa Club at Rådmansgatan. Friday evening is also the time for the infamous E&Y “after work”, which has made them regulars at StureP.
Personality
Nils is an extremely driven person with high ambitions and that is being reflected into his work, which tends to keep a really high pace with all the projects and meetings he has to keep track of. Being organized and on time are the essences of what makes his daily life go around. He also prefers to spend most of his time being active and around people, which can sometimes be a problem since he, like most people, tend to care too much of what people think. Things like dressing nicely, tanning, traveling and watching Paradise Hotel are things Nils values among all else.
Today
Just as Kicki, Nils takes the morning commute to work and despite the mass of people he has to shoulder his way through, he makes sure to catch every train. He feels like it is as much business at work as it is to work, often having somewhat of a temper seeing as he feels that his time is more worth than others around him on his commute. His worst pet peeve is other people not making enough room for him on the train.
Hanna’s Scenario, “No Power Outlet”:
Nils is making his way home from work on a Wednesday evening. Since he and his team at E&Y is right in the middle of closing an important deal he had to stay at work a bit later than usual. It’s 19:30 already, which isn’t such a big deal if it happens only once in a while, he’ll just pick up some take-out on the way home from the train for him and his girlfriend so they don’t have to cook (although take-out happens perhaps more often than necessary…).
One good thing about going home later though, to Nils delight, is that the train is a little less full! Perhaps he’ll even get to sit down. Nils dreams about how wonderful his commute home will be now, as it happens only once in a blue moon, that he won’t have to stand pressed together with everyone else. He even dares to dream about sitting down at his computer and finishing up some of the reports after the busy day at work, not wasting a minute off effective time. Everything is bliss, until he actually gets to sit down at the train (he got a seat!), opens up his computer and realizes that it’s out of battery… And all the seats next to outlets are already taken. Hmm… seems like he won’t be able to use this short (precious, according to him) time slot for anything productive after all. He puts his computer away and relaxes instead, but is still a bit bitter about it all. Well, you can’t have everything, he thinks, but deep down he really wishes he could.
Yrin’s Scenario:
As Nils entered the train at Jakobsberg, a cool breeze swept a tiny---tiny almost to the point of invisibility, yet still noticeable to an attentive eye---speckle of dust off his black cashmere sports coat. The culprit? The finish on the storage boxes under his brand new Codutti desk, of course. Of course---this desk has caused him problems ever since it arrived. His mind started shaping up a kind but stern letter to the Key Account Manager of their office furniture supplier when---
- DING. Nästa station T-Centralen.
Immediately the focus of his thoughts changed. Work had been going smoothly today, so smooth in fact that the never-to-be-missed Friday After Work---or FAW as it's known internally---tonight would start much earlier than normal. While his colleagues applauded this, Nils and Olle were hit hard by this decision. While Olle had to bring his kids home from school before going to the FAW, Nils was committed to attending a teleconference with a key customer in Whangaruru, New Zealand. As luck would have it, the meeting was short, but he was still at risk of arriving last to the FAW. Last. Yes, that's right. Not just late---later than Olle---but last! Nils never lets himself be left behind, ever. Being last is---simply put---the last option. The very last.
He quickly grabbed his phone, logged on to the company compute cluster and attached to the simulation software. You see---one of his projects involves real time simulations of passenger flow in major transport hubs. It just so happens that T-Centralen is the main experiment site, with hundreds of cameras and sensors feeding information into the simulation.
As anyone who has tried to rush through a busy train station knows, some parts of the path are very easy to navigate. You can easily get up to a good jogging speed. You're getting from point A to B, almost in a straight line, and then---BAM---like hitting a wall---YOU. ARE. NOW. STUCK. Stuck behind some old fellow, or, surprisingly---surprising to Nils anyway---some young, perfectly fit individual, who's just completely lost as to his or her whereabouts.
That's where the fluid dynamics comes in. In the project, the objective is to predict where and when these blockages will occur, thus enabling a re-routing of the flow of passengers in a preventive manner. Or, as was the case this evening, just trying to get Nils to avoid the blockages---so that he could run past all the inefficient people. That way he would at least not end up last.
As the doors of the red line metro train shut, Nils glanced at his phone before putting it in his tailor-made phone pocket with built in charging capability. Ninety-four percent. Ninety-four percent! He'd reached ninety-four percent of his MHR---maximum heart rate. Yes, that's the measure of success in this project: the peak fraction of a test subject’s maximum heart rate that is achieved. Ninety-four percent, Nils thinks while smiling to himself. That's not bad. Not bad at all.
Elisabet’s scenario: “No room on the train!”
Nils is on his way home, a tuesday late afternoon, 5:30 pm, prime congestion time. He knows that the train will be at it’s fullest, but isn’t scared to break his record he has managed to keep for an entire year: to never have to wait until the next train and always be able to board the one coming, without being pushed out by the people onboard.
He waits for the train, but pays all his attention to candy crush on his phone, which results in him not being ready when the train arrives. He is standing too far back, and when everyone boards the train before him, there is simply no room left for him on the train! This cannot be true! But he is not about to push the little kid standing closest to the doors, and so he lets the doors close shut. Darn it! His record is broken… he feels like he has betrayed himself. It’s a bad day for his self esteem.
The next train is in 5 minutes, and this time he is more ready: he walks to the center of the platform and stands close to the edge, ready to be the first person to board the next train (even before the others have time to get off..? Well, we’ll just have to wait and see… Nils’ skills are close to unbeatable).
Making of persona and scenarios
Persona (Axel)
I started creating my persona (Nils) by imagining a person in my mind that would interact with an environment that were relevant to our project. Through the information we already had from our field study and inevitably my own cultural knowledge, I created a person roughly based of the step-by-step image shown below.
It is especially important to focus on the user characteristics, from where you capture the key attributes to make your persona seem as alive as possible when facing the different scenarios. One persona could originate from a lot of different real users’ information you’ve gotten through data gathering, i.e field studies. The focus here is to make the persona feel as realistic as possible.
Scenario (Hanna)
When creating my scenario I tried to think of Nils’ needs and requirements, and picking one to make an example out of. According to the book, creating a scenario is a bit like telling a story, and the effect (benefit) is that all stakeholders, regardless of background knowledge, will have an easier time understanding and relating to a problem they are trying to resolve through a scenario, as it takes away focus from the technology and puts it onto the user instead.
As Nils’ finds it important to use time effectively and would like to find an outlet for his computer charger on the train one probable scenario is that the seats next to the outlets are taken and they are not available. This poses indicators of potential design choices to make the situation better, perhaps move the outlets or make more of them. But perhaps there is another way to solve it? By including Nils’ thoughts in the scenario as backed up by his persona description it is easier to see the situation from his perspective; what would he be capable of or willing to do himself in order to fix the problem, how much does it mean to him? Through this way of thinking more accurate solutions might be reached rather than tackling the problem “head first” as a designer.
Scenario (Yrin)
Scenarios should be written to focus on human activities, rather than specific human-computer interactions. Accurately describing preexisting behaviors and expectations can help give rise to ideas about new ways of solving problems. That way, interactions can be designed with user motivations in mind. (My conclusion based on a brief literature study.) The course book (Interaction Design 3rd ed., sec 10.6.1) encourages the dramatization of scenarios, in order to make users' needs more understandable to developers.
With this in mind, I deliberately designed my scenario so that Nils would have an extreme need of fast and efficient travel. In doing so, I left out the perspective of the typical user. My hope is that this would open up a wider solution space, as slow-moving public transport is such an every-day occurrence that I think many people hardly notices it as a problem to be solved. To further emphasize this part of the solution space, I chose to present an interaction scenario based on a power user of a "future" technology (i.e. real time crowd movement simulations).
I think there is some room for self-criticism about this latter decision, as it constrained the downstream design process by taking an "app centered" approach to establishing the requirements of the project. This is, however, a more general issue with the project at large, due to time constraints and the focus of the course (especially the exercises). Even though "non-app" solutions were explicitly allowed, it wasn't much discussed in the group as wasn't really seen as the "point of the course". (My interpretation.)
