I expanded on my blog post on this topic and wrote an article for Smashing Magazine: Designing For Smartwatches And Wearables To Enhance Real-Life Experience.
Now that smartwatches and wearables are in a huge growth phase, I shared my ideas on treating the real world as your primary interface, and developing app experiences that enhance our lives, rather than needlessly distract.
Lately, I have been doing a bit of work designing products for smartwatches and wearables. It’s a challenge, but it is also a lot of fun. I’m just getting started, but I’ll try to describe what I have learned so far.
Designing for these devices has required a shift in my thinking. Here’s why: we have a long and rich history in User Experience (UX) and User Interface (UI) design for programs written for computers with screens. When we made the leap from a command line interface to graphical interface, this movement exploded. For years we have benefitted from the UX community. Whenever I am faced with a design problem when I’m working on a program or web site, I have tons of material to reach for to help design a great user interface.
That isn’t the case with wearables because they are fundamentally different when it comes to user interaction. For example, a smartwatch may have a small, low-fidelity screen, while an exercise bracelet may have no screen at all. It might just have a vibration motor inside and a blinking light on the outside to provide live feedback to the end user.
So where do you start when you are designing software experiences that integrate with wearables? The first thing I did was look at APIs for popular wearables, and for their guidance on how to interact with end users. I did what I always do, I tried to find similarities with computers or mobile devices and designed the experiences the way I would with them.
Trouble was, when we tested these software experiences on real devices, in the real world, they were sometimes really annoying. There were unintended consequences with the devices vibrating, blinking, and interrupting real world activities.
“AHHHH! Turn it off! TURN IT OFF!!”
Ok, back to the drawing board. What did we miss?
One insight I learned from this experience sounds simple, but it required a big adjustment in my design approach. I have been working on software systems that tried to make a virtual experience on a computer relatable to a real-world experience. With wearables devices that we literally embed into our physical lives, that model reverses. It can mess with your mind a bit, but it is actually very obvious once it clicks in your brain.
Simply put, when I don’t have a UI on a device, the world becomes my UI.
Let me expand on my emerging wearable design approach to help explain why.
If you’ve been developing software for computers and mobile devices already, this may sound simple, but it can actually be a difficult concept to nail down.
One approach I take is to reduce the current features. If we cut this feature, does the app still work? Does it prevent the end user from solving problems or being entertained? If we can cut it, it might be a supporting feature, not a core feature. Remember, wearables have less power and screen real estate, so we’ll have to reduce. When I had a group of core features remaining, now it is time to summarize. Can we describe what these features do together to create value and a great experience for users?
Another approach I use is to abstract our application away from computing technology altogether. I map out common user goals and workflows and try to repeat them away from the PC with a paper and pen. With an enterprise productivity application that involved a lot of sharing and collaboration, I was able to do this with different coloured paper (to represent different classes of information), folders (to represent private or shared files), post-its and different coloured pens for labelling, personalization.
In a video game context, I did this by reducing the game and mechanics down to a paper, pen, rule book and dice. I then started adding technology back until I had enough for the wearable design.
Now, how do you describe how you are different? Have you researched other players in this market? Who are your competitors, or who has an offering that is quite similar? How are you different? What sets you apart in a sea of apps and devices? This is vital to understand and express clearly.
How do I know if I am done, or close enough? As a team, we should be able to express what our product is and what it does in a sentence or two. Then, that should be relatable to people outside of our team, preferably people we know who aren’t technologists. If they understand the core offering, and express interest with a level of excitement, then we are on our way.
If you are starting out new, this can be a little simpler since it is often easier to create something new than to change what is established. However, even with a fresh, new product, it is easy to bloat it up with unneeded features, so have the courage to be ruthless about keeping things simple, at least at first.
With wearables and mobile devices in general, the technology is very different than what we are used to with PCs. I call them “sensor-based devices” since the sensors are a core differentiator from PCs and enable them to be so powerful and engaging to users. The technical capabilities of these devices are incredibly important to understand because it helps frame our world of possibilities when we decide what features to implement on wearables and smart watches. Some people prefer to do blue-sky feature generation without these restrictions in place, but I prefer to work with what is actually appropriate and possible with the technology. Also, if you understand the technology and what it was designed for, you can exploit its strengths rather than try to get it to do something it can’t do, or does very poorly.
This is what I do when I am researching a new device:
Now we can put together our core value proposition and the device’s capabilities. However, it’s important to understand our target market of users, and where they will use these devices, and why. I’ve been calling these types of stories different things over the years: technical fables, usage narratives, expanded scenarios and others, but nothing felt quite right. Then I took the course User Experience Done Right by Jasvir Shukla and Meghan Armstrong and I was delighted to find out that they use this approach as well. They had a better name: impact stories, so that is what I have adopted as well.
What I do is create an impact story that describe situations where this sort of technology might help. However, I frame them according to people going about their regular everyday lives. Remember that stories have a beginning, middle and end, and they have a scene, protagonists, antagonists, and things don’t always go well. I add in pressures and bad weather conditions that make the user uncomfortable, making sure they are things that actually occur in life, trying to create as realistic situations as I can. Ideally, I have already created some personas on the project and I can use them as the main characters.
Most people aren’t technology-driven – they have goals and tasks and ideas that they want to explore in their everyday lives and technology needs to enable them. I try to leave the technology we are developing out of the picture for the first story. Instead, I describe something related to what our technology might solve, and I explore the positives, negatives, pressures, harmonies and conflicts that inevitably arise. From this story, we can then look at gaps that our technology might fill. Remember that core value proposition we figured out above? Now we use this to figure out how we can use our technology platforms to address any needs or gaps in the story.
Next, we filter those ideas through the technical capabilities of the device(s) we are targeting for development. This is how we can start to generate useful features.
Once we get an idea on some core features, I then write three more short stories: a happy ending story (what we aspire to), a bad ending story (the technology fails them, and we want to make sure we avoid that) and a story that ends unresolved (to help us brainstorm about good and bad user experience outcomes.)
Impact stories and personas are great tools for creating and maintaining alignment with both business and technical stakeholders on teams. Stories have great hooks, they are memorable, and they are relatable. With experienced people, they remind them of good and bad project outcomes in the past, which help spur on the motivation for a great user experience. No one wants their solution to be as crappy as the mobile app that let you down last night at the restaurant and cost you a parking ticket.
UX experts will tell you that concrete imagery and wording works better than abstract concepts. That means if you have a virtual folder, create an icon that looks like a folder to represent what it is by using a cue from the physical world. What do we do if we have no user interface on a device to put any imagery on it at all? Or maybe it is just very small and limited, what then? It turns out the physical world around us is full of concrete imagery, so with a bit of awareness of a user’s context, we can use the real world as our UI, and enhance those experiences with a wearable device.
Alternate Reality Games (ARGs) are a great source of inspiration and ideas for this sort of approach. For a game development project I was working on, I also looked at Geocaching mechanics. Looking to older cellular or location-based technology and how they solved problems with less powerful devices is an enormous source of information when you are looking at new devices that share some similarities.
I talked to a couple of friends who used to build location-based games for cell phones in the pre-smartphone era, and they told me that one trick with this approach pick things that are universal (roads, trees, bodies of water, etc.) and add a virtual significance to them in your app experience. If I am using an exercise wearable, my exercise path and items in my path that I pass by might trigger events or significance to the data I am creating. If you run past significant points of interest on a path, information notifications to help cheer you on can be incredibly rewarding and engaging.
One thing that bugs me about my smartphone is that it rarely has situational awareness. I have to stop what I am doing and inform it of the context I am in and go through all these steps to get what I want at that moment. I want it to just know. Yesterday I was on my way to a meeting in a part of town I am bit unfamiliar with. I had the destination on my smartphone map, without turn by turn directions turned on. I had to take a detour because of construction, so I needed to start a trip and get turn-by turn directions from the detoured area I was on. I pulled over to the side of the road, pulled out my smartphone, and I spent far too long trying to get it to plan out a trip. I had to re-enter the destination address, get the current location I was at and mess around with it before I could activate it. A better experience would be a maps app that would help and suggest once it senses you have stopped, and allow you to quickly get an adjusted trip going. While you have a an active trip, these devices are quite good at adjusting on the fly, but it would be even better if they knew what I was doing and suggested things that would make sense for me right now, in that particular situation.
It is easy to get irritating and over suggest and bug people to death about inconsequential things, but imagine you are walking past your favorite local restaurant, and a social app tells you your friends are there. Or on the day you usually stop in after work, your smartwatch or wearable alerts you to today’s special. If I leave my doctor’s office and walk to the front counter, a summary of my calendar might be a useful thing to have displayed for me. There are many ways that devices can use sensors and location services to help enhance an existing situation, and I see a massive amount of opportunity for this. Most of the experience takes place in real life, away from a machine, but the machine pops up briefly to help enhance the real life experience.
If we create or extend a narrative that can make real world activities also have virtual meaning, that can be a powerful engagement tool. One mobile app I like is a jogging app that creates a zombie game overlay on your exercise routine. Zombies, Run! is a fantastic example of framing one activity into a context of another. This app can make my exercise more interesting, and gets your brain involved to help focus on what might become a mundane activity.
With a wearable, we can do this too! You just extend the narrative of what you created on your job and delay telling you what happened until you are complete, and have logged in to your account on a PC or smartphone/tablet. You have to reinforce the imagery and narrative a bit more on the supporting apps on devices with a screen.
ARGs really got me thinking about persisting a narrative. It is one thing to apply virtual significance to real-world objects, but what happens if we have no user interface at all? What are we left with? The most powerful tool we have access to is our human brains, so why not use those too? Sometimes as software designers I think we forget about how powerful this can be, and we almost talk down to our users. We dumb everything down and over praise them rather than respecting that they might have different interpretations or alternative ways of creating value for themselves with our software. Just because we didn’t think of it doesn’t mean it has no merit. It does require a shift towards encouraging overall experiences rather than a set of steps that have to be followed, which can be challenging at first.
If you are working with a wearable that doesn’t have a screen or UI, and is essentially a measuring device, one option to tie in your app experience is to think of converting the data from one context into another. This can be done by tying into APIs for popular wearables. You don’t have an app on the device, but your device ties into the data that is gathered by it and used for something else. For example, convert effort from an exercise wearable into something else in your app. One example of this is Virgin Pulse, an employee engagement application that has a wearable that tracks exercise. Exercise with the wearable can be converted into various rewards within their system. The opportunities for this sort of conversion of data that is measured for one purpose to another experience altogether are endless.
One app I designed extended data generation activities to a narrative in an app. We extended the our app concepts to the physical activity and tapped into the creative minds and vivid imaginations of the humans using the devices with a few well placed cues. This was initially the most difficult app for me to design, but it turned out that this was the overwhelming favourite from a “fun to use” perspective. The delay between generating the data out in the real world, and then coming home and using your PC or tablet to discover what your data measured by the wearable had created in our app was powerful. Anticipation is a powerful thing.
However, be careful when you do this. Here are a couple of things to be aware of:
It can be really boring to use a device that just does the same things over and over. Eventually, it can just fade into the background and users don’t notice it anymore, which causes you to lose them. If they are filtering out your app, they won’t engage with it. Now, this is a tricky area to address because the last thing you want to do is harass people or irritate them. I get angry if an app nags me too much to use it like some needy ex, or try hard salesman. However, a bit of design work here can help add some interest without being bothersome, and in many cases, add to the positive experience.
Here are some simple ideas on adding variation:
As we learned when designing notifications for a smartwatch, it can be incredibly irritating if it is going off all the time and buzzing on your wrist. Since wearables are integrated with our clothing, or worn directly next to our bodies, it is incredibly important to provide options and control for users. If your app is irritating, people will stop using it. However, one person’s irritating is another person’s delight, so be sure to allow for notifications and vibrations and similar affordances in your product to be turned on and off.
This is one of the most fun areas for me right now in my work, and I hope you find my initial brain dump of ideas on the topic helpful. Sensor-based devices are gaining in popularity, and all indications show that some combination of them will become much more popular in the future.
This is Part 2 of my interview with Anna Sort. If you haven’t already, check out Part 1 of the interview. Anna is a professional nurse who is working to bring together smartphone and video-game technology into healthcare. She is also an Associate Professor at the University of Barcelona, and works both as a gamification and as a serious games consultant.
Jonathan: What can go wrong with a system that utilizes technology and gaming mechanisms with a worldwide pool of contributors (aka “the crowd”)? For example, how do you design your game to prevent or deal with the abuse the rules or take advantage of bugs or loopholes?
Anna:
I think you cannot really prevent people from trying to cheat in a game, it is part of the challenge and the fun for some people to try to exploit games, so you just have to do your best designing to make it fun to play the regular way rather to make it “uncheatable.”
In our World of Warcraft diabetes add-on we are still deciding if we want the add-on in itself to be fun or not. However, what is clear is that if people wantsto cheat they are allowed to. The add-on is created to fit an exploring environment rather than a “win” situation, it is there for the player to decide whether to play using risky behavior and try what happens if you mix certain things/eat certain foods or to try their best to always “keep in track” with their glucose. It will definitely be exciting as well to see what people will do with the add-on in the end! We are here to learn about how people interact and react to “serious gaming” (using an already existing game for other learning purposes).
Jonathan: What are the biggest challenges you face from a design perspective to create something that people will interact with? How do they apply their virtual learning to their own real lives?
Anna:
This is a very interesting question and is something we ask ourselves. This isn’t explored that much in “serious games” in general. We hope to find out more about this with this experiment. However, we hope to help people understand how the diet and exercise affects diabetes, so in this first experiment we aren’t looking to change behavior in real life, but we will have a couple of questions regarding whether users have made any changes in their lifestyle at the end of the experiment.
Jonathan: What does success look like for your World of Warcraft Diabetes mod project?
Anna:
This is a very difficult question. In this first trial it will be complicated to have a bar to measure to say: “Yes, I’ve succeeded”. At the moment we are working on the add-on but there is a lot of work to do regarding questionnaires. How many will download it? How many will play it? What will be their reaction? There is a lot of work still to be done to determine a good answer for this question.
Jonathan: No problem. When you are truly innovating, you don’t really know until you try out an idea, discover what happens, and refine. Moving on, what new thing/trend/innovation are you keeping your eye on at the moment? Is there anything else you’d like to share with us?
Anna:
I’m very much into gamification and self-tracking apps. I’m a nurse so I’m all about prevention and I think mHealth (mobile health) offers us a great opportunity to focus on that and giving the user tools to take charge in their well being, lifestyle and health.
For more on these ideas and more, check out Anna’s latest presentation: Video Games and Gamification for Health Care .
Jonathan:
Thank you again Anna. I hope for the best in your work, and thanks for contributing to something that is important to all of us!
If you’d like to help out Anna with her WoW diabetes mod project, contact me and I’ll put you in touch with her and her project team.
For my first blog interview in my Designing a Better Life series, we will be chatting with Anna Sort. Anna is a professional nurse who is working to bring together smartphone and video-game technology into healthcare. She is also an Associate Professor at the University of Barcelona, and works both as a gamification and as a serious games consultant. I find Anna inspiring because she is working hard in the area of mHealth (mobile health) and games for health.
Anna Sort speaking at the Gamification World Congress
Anna is based in Spain, and graciously agreed to this interview in English for me, and for you, our readers. For more about Anna, check out her blog: Lost Nurse in the Digital Era and these two videos on youtube of her presenting: Designing Games as a Nurse, Gamification of Health Products.You can find her on Twitter here: @LostNurse.
Jonathan: Please tell us a bit about yourself. How did you get involved in the games for health field?
Anna:
I have always been a gamer but programming never attracted me. I was looking for a job as a nurse abroad when Blizzard Entertainment called me to be a customer support representative in France. They offered to take care of housing and banking, making it easy to move and start work in a new country. Also the multinational office work was something I had always wanted to try (and being a CS for the game World of Warcraft also seemed very cool). After 6 months I took the nurse spot in the company, and being a gamer working with gamers made me realize how much easier it would be to communicate and experiment some health information through games rather than 30 minute talks plus a flyer to never read at home.
After a while I started to look for Masters degrees that would allow me to go into a “techie-nurse” path. I found an interesting Master’s degree called CSIM, which was focused on a multidisciplinary approach to problem solving. I was the only healthcare student in the class, most of my classmates were designers, artists and programmers, but surprisingly 2 of the 8 Masters Thesis projects would have benefited from a healthcare professional, a rehabilitation system and an exergaming platform. In a way that reassured my idea that this “new profession” I wanted to pursue would eventually exist.
My thesis was about the quantity of exercise the children did while playing on an inflatable slide that had a game projected on and kids interacted with through an infrared system (it’s called an “exergaming platform”). I took part in the game design as well as the exercise experiment for my thesis so it was really interesting. I worked on a multidisciplinary team and I loved it. After my master’s I started my career alone, and soon enough I was contacted by Homero Rivas in Stanford, whom I talked about my vision in games and we are currently developing with MIT the first World of Warcraft health add-on to raise awareness on Diabetes.
Jonathan: The research and work that you do sounds fascinating. Can you explain how your work can help make our lives better?
Anna:
Behavior-wise humans are prone to play, and games offer a wide variety of play, such as exploring, competing, collaborating and self expression. Taking gaming into healthcare is a way to make taking charge of one’s health more interesting, intriguing and motivating. It is not about making fun of having diseases or trivializing them, making it less important because it’s a game. It’s about providing the tools and inspiring the motivation and behavior change to be healthy and improve your lifestyle.
Jonathan: I love your World of Warcraft Diabetes mod project. Can you tell us about this project and your goals? Is there anything we can do to help you?
Anna:
Thank you. It is a very exciting project indeed, and challenging! Especially because the game World of Warcraft has a pool of 9 million users, which means if 5% of these users download and play the add-on, we will have the biggest Health Game research experiment ever made!
The add-on is an “add” on the game which you download that changes the user interface. What we have done is add a glucometer on the side that is impacted by the player’s actions, such as running, fighting and eating foods. World of Warcraft has a lot of foods, drinks and alcoholic beverages so it makes the experimentation part very interesting. It isn’t focused on the disease itself, as we are aware not everyone reacts the same way to foods and drinks, and compositions aren’t equal worldwide. We want to raise awareness, and maybe even make new users having youngsters encourage family to play to see what is it like to live with diabetes.
We are not sure what people we will attract and we also are still debating whether we should gamify the add-on or if the game is good enough as-is people will still enjoy the game with the add-on. All the steps should be taken care of very wisely as the amount of research information might overwhelm us otherwise and turn out to be unusable.
How can people help? We still need a good experiment designer to take part of the team, so anything on that regard is helpful. And programmers. Hands are always needed!
Jonathan: What design concepts do you find the most useful for this project?
Anna:
Possibly the most important part of our design process will be focused on the tutorial. World of Warcraft has an excellent tutorial to help new players get on board, and since the new players we might attract will already have a whole game to learn, we want to make sure the on-boarding of the add-on doesn’t collide with the game tutorial and so it doesn’t overwhelm the player.
Stay tuned for Part 2.
Often, my public work lags behind my current interests or passions. That’s ok, it usually catches up in time. However I wanted to talk about my current focus and passion right now: designing systems for a better life. If you read my blog regularly, you will notice a shift towards design, user engagement and other topics. I wanted to explain why.
This has been a tough year. I’ve been on the road a lot, and I have met a lot of fantastic people and worked with some amazing organizations. However, I have been away from my family and friends here at home, and I have missed out locally. The Alberta flood disaster forced me to look at my local, real life. This spring we found ourselves evacuated from our home, staying with friends wondering if the flood would wipe out our house and property. Unlike many others, we were very fortunate and came home to no damage, but it changed our perspective. A few days earlier, we took for granted that we had a safe, dry, secure home to always use as a refuge no matter what happened in our work or public lives. We came home and celebrated with our neighbors that we were all ok, and then we did what we could to help each other. I realized I need to do more to contribute to my local community as well as virtual communities.
The Alberta floods, like so many natural disasters, brought the best out in people. Organizers were turning away volunteers because they had too many, and entrepreneurial types turned their energies towards creating systems to harness that energy and that willingness to help others. I was amazed at how people used social media to mobilize people to work for a common goal and to help out others. Mobile technology wasn’t just about screen sizes and sensors and wireless conditions or merely staying informed about the emergency going on around them, (which was incredibly useful and important.) What was more interesting was the technology was helping people help others, and to mobilize together to collaborate. This is incredibly powerful. The technology enabled people to do something in real life. It wasn’t just about sharing pictures of food and videos of cats on social media, or wiling away hours playing Candy Crush or Angry Birds. This technology was exploited to make all of our lives a bit better as we lived through a natural disaster together. Those who were unaffected and wanted to help just had to grab their mobile device and utilize social media to find out what they could do to help. Those who were affected could get informed, ask for help or just read messages of encouragement.
Mobilization and collaboration to help work together to help others or to solve problems is an important area that I am exploring through human and technology systems.
Mobilization can be harnessed for helping organizations and groups of people solve really hard problems. Distributed computing can be combined with crowdsourcing to distribute problem solving amongst our most powerful tool at our disposal: the human brain. Projects like fold.it provide problems in a gaming context to help provide vital information for researchers who are looking at combating disease, or providing health care technology to improve our lives. These are enormous problems that have an impact on all of us. On a smaller scale, we can focus our energy and mobilize the people in our social circles to help us achieve health goals or recover from injury with the SuperBetter game created by Jane McGonigal. These are two powerful examples of how we can use technology and humanity together to solve problems.
Those of you who follow my writing know that this is an area that is important to me, even on simple tasks like test automation where I prefer human involvement in the computing work (see Man and Machine: Combining the Power of the Human Mind with Automation for more.) In the past, we have tried to outsource difficult problems to machines, and now we are learning better ways of getting the best of both worlds – the computing systems support us and do what they do well and enable us to really take advantage of collective wisdom and interests. I think we are just scratching the surface on this space.
Distributed collaboration to solve really hard problems is an area I am looking into more.
I’ve done a lot of work with mobile applications, and many of you are familiar with my book and course on testing mobile applications. I have trained hundreds of people, and many more have read my ideas about testing mobile apps or web experiences, but that is only part of the picture, and I do a lot more in this space than my public work suggests. To create a great mobile experience, we need vision from business leaders on how they want to use the tech – are they merely supporting it, or are they embracing mobile technology to transform their interactions with the people they are trying to help? Are they looking at mobile as something they are forced into, or are they looking to it as a new area to help increase revenue and loyalty? If business leaders are reluctant, that vision (or lack of vision) will make its way all the way down through the project, and ultimately in a poor customer experience. On the other hand, a great mobile vision is only as good as the technology that was chosen, the design of the application, and the quality of the customer experience. I have been helping organizations to create great mobile experiences in each of these areas.
A quality mobile experience requires great vision, careful choice of technology, a design that engages customers, and is reliable for people who are on the move in the real world. That reliability also depends on great design, programming and testing. That quality experience can’t be tested in at the end, so many organizations are asking for my help in other areas, such as a mobile strategy from an executive level, how to choose the best mobile technology to fit that vision, what areas need to be addressed in mobile design, and then quality practices in programming and testing. This is a fascinating area to work in, because there are many more areas to be aware of than we are used to in software development.
A fantastic mobile experience from project vision, design and execution on down to you, the person holding the device, can make your life easier, but a poor quality experience can ruin your day. I am learning how to improve this experience and I want to show you how you can too.
Some of you have wondered why I am talking about things like gamification. I am less concerned about the gaming aspect, I am more concerned with what lessons we can learn from this field with regards to collaboration and finding meaning in what we do. Modern knowledge work can be difficult to deal with over time. If the power goes out, all our work disappears, so many struggle to find motivation and meaning in their work and careers.
To me, gamification is just one of several potential models of engagement, and we can use it in different ways. If you are in a job that is difficult and you are losing hope, don’t be threatened if I talk about gamification. If making your work more like a game fits your context and your personality, as well as the people working with you, then yes, we might look at creating some sort of Alternate Reality Game (ARG). Always know I would never force that if you weren’t interested, or if it wasn’t appropriate. However, I may use mechanisms that I have learned from game designers to help with areas of work that are difficult, feel hopeless and don’t have meaning. If I do it correctly, you won’t recognize it as a game – I won’t just put up superficial gold stars and leaderboards, or worse, trivialize the important work that you do. I may however, collaborate with you to create something to help you get more meaning in what you do using engagement or other concepts I have learned from games.
That is vital in human and software systems that people work with. Can we make this activity or program engaging so they want to use it more? Can we design the system to not only solve the problems of an organization, but also to help reinforce meaning in what people do? Gamification is an interesting and powerful area of research, with a lot of potential for good, but it can also create harm. I am carefully researching how I can use this in my own work, because it is one mechanism that I see to help do something more for us.
Studying engagement models and finding and experiencing meaning in the things we spend our days working at is important and I am spending more time looking at how the intersection of software and people systems can help.
Design principles are another area of research and problem-solving for me, which are often under the umbrella of UX (User Experience). Creating great software experiences can really help us since we interact with it, or it affects us indirectly in everything that we do. A better software or computer system experience has an enormous impact on our lives. When they go wrong, they can really cause problems, but a simple, elegant solution can bring joy. User experience and design in an era where wireless and sensor technology is common, touch and gesture interaction on different technology with different screens is hard enough. What do we do when nanotechnology and other distributed or pervasive systems become much more common? I love the research and work in this space, and it is a part of what I do on projects.
The challenges we have are fascinating, so product management and product design are areas of project work for me, and what I am increasingly spending time on in my spare time.
Some of you have heard me talk about health projects. One of the most rewarding projects of my career was working on a medical program for mobile devices. It was great to try to break new ground with new technology, and determine how we could make health-care professionals lives easier, and to enable them to provide better patient care. My Mother still works as a medical professional, it is a calling, and we tease her that if she refuses to retire, she’ll pass on “in harness”. She is absolutely fine with that, she is committed to her work and patients, and takes courses every year on areas that interest her, and how to better use technology in her own work. She has passed that down to me, and finally as a professional, I have had some chances to help create better software for medical professionals. I enjoy working on medical software because I can see how we are contributing to actually make people’s lives better. When we do it right, we enable others to do great work, solve difficult problems and help real people. It’s easy to find meaning when your work has an impact on others, and we can do so much better with technology and health than we have been.
Systems that help us live more healthy lives are an area of keen interest for me, and I am interested in mobile, games for health, distributed computing, crowdsourcing and all sorts of things in that space. Healthcare professionals like Anna Sort inspire me with their creative and innovative ideas that they turn into action, and programs like Strokelink to help stroke patients using mobile technology are great.
I’m also interested in how we can create software for health professionals that is easier to use, more reliable, and enables them to focus on patients and not fight with systems that don’t take them and their unique context and work as well as the environment they are working in into account.
Finding ways to use software and related technology in health care and health research is another area of huge interest for me.
So there you have it. Watch this space for more of the above topics on how we can explore the intersection of people and technology to help design better lives for ourselves.
As a travelling consultant, I get insight into a lot of organizations. One theme that I see over and over is a lack of understanding about mobile experiences among decision makers and technical teams. When it comes to interpersonal or written communication, companies have sensible rules and practices about making that exchange great. You’ll hear or read slogans about treating the customer right, or to go beyond and satisfy and impress them. Most organizations have great alignment on that message, and when I walk into an office, I am greeted by friendly security and front office staff who smile, are pleasant and help me get to where I need to go. They want all of us to have a great first impression, so they invest in human-friendly lobbies with art, comfortable furniture, and great lighting. This extends to email and voice communications as well. People try to be professional, pleasant, and make me feel welcome as a customer or consultant. However, that is rarely my first impression of that organization. For me, and millions like me, I get my first impression of that organization through their mobile experience.
In many cases, that mobile experience is the opposite of their interpersonal customer service. They fail to realize that a bad digital experience is just plain old bad customer service. It is the virtual equivalent of a rude call center employee, or an office administrator who tells me to go f— myself when I walk through the door. Instead of feeling valued by the organization, my mobile experience feels like they don’t care. They make me feel confused (what does this company do?), they make me feel frustrated (I can’t solve the problem I need to sort out!) and that they don’t value my time (why do I have to gesture so many times and spend so much time to do a simple task?)
These organizations would be horrified if I was flipped off when I walked in the door, but they have no problem making me feel just like that when I try to interact with them virtually on my mobile device. And they don’t seem to have a problem with it. On the other hand, organizations that realize great customer service extends to digital experiences have alignment on their customer-first values. Instead of worrying about mobile frameworks and handsets and technology development, they seek the solutions that provide a great customer service on virtual mediums. Thankfully, that means we have a lot of examples on how to do it well.
Here is an example of contrasts: airline mobile experiences. I won’t name names, but I will describe 3 different mobile experiences and the technology they are using to either create great customer service, or do the digital equivalent of flipping us off.
I travel a lot, and when I am travelling, I need the following at a minimum:
Let’s look at three different mobile experiences from three different airlines:
How do they stack up?
App 1 (native):
App 1 overall customer experience: great!
This app has really improved my flying experience and I am growing to like this airline more over time.
App 2 (hybrid – combo of web and native technologies):
App 2 overall customer experience: poor.
Every time I use the app I get frustrated and I project that frustration on the airline. In one case, I was having trouble checking in at a kiosk, so I opened up the app. It gave me a cryptic error message that made me feel like my flight had been cancelled. I had to stand in a line up for a half hour to find out from a human to look into the problem and sort things out. This app requires workarounds (save my booking reference in a note or search for an email confirmation and screen shots of up to date data) to be even useful when I fly. They chose hybrid to get cross platform support, yet they don’t even take advantage of the affordances of a hybrid app.
Web 1 (mobile web site):
App 2 overall customer experience: Rage inducing.
When this app lets me down in an airport because it takes too long to get anything done, I look longingly at the competition counters across the hall. This experience is beyond useless and it causes me to lose faith in the organization as a whole. If this is so painful, how is the flight? Also, I found that staff members have very little faith in the mobile experience. Even though I had a PassBook ticket that was valid, they reprint a hard copy when I try to board the aircraft because they “don’t trust the mobile app”. PassBook integration is one thing they do well, but people get so frustrated with an experience that doesn’t fit the needs of customers and staff on the front lines hear about it and try to adjust.
So whose app do I use the most? App 1 of course, and I also fly with them the most. I get a great customer experience with their mobile app, and they also do a decent to please us in their interpersonal interactions. The airlines that supply App 2 and Web 1 actually have better interpersonal interactions – they are friendlier and more helpful, but the mobile digital experiences are not convenient, so I don’t fly with them as often. This has less to do with the technology they have each chosen, but in how they have chosen to implement it and whether they are making technical decisions or customer-serving decisions in how they create mobile experiences.
A great customer experience that enhances convenience goes a long way. In fact, I will put up with less than ideal interpersonal interactions with a company if their mobile experience is convenient and makes my life easier. Next time you are looking at your mobile experience, no matter what the technology, ask the question: are we creating a great customer experience with our technology as well as with our people? The extent to which you use mobile technology to address that means much more to your customers than just “going mobile” and putting something out there. In some cases, no mobile access is better than one that makes people hate your company.
In an upcoming post, I’ll talk about ways our hybrid and web-only airline friends can improve their mobile customer service.
I wrote an article for Better Software magazine for the July/August 2013 issue about innovation in processes. The PDF of the article is available here: Things Change (And So Should Processes) and you can download the entire magazine here: Better Software July/Aug 2013.
Many teams struggle when a process lets them down because their unique situation and mix of people, technology and target market don’t fit a generic process. It’s also surprising to find out how old many of the popular processes we are trying to follow are. The technology we are creating has changed a great deal since the 1990s, so why are we surprised when processes created in the ’90s let some teams down?
Instead of feeling guilty that they aren’t following the crowd and doing what the experts tell them to do, I encourage teams to take pride in their innovation not just in technology, but in how they create powerful processes for themselves.
Recently, I wrote about Using Storytelling Games in Software Testing, and pointed you to a paper by Martin Jansson and Greger Nolmark. Now I want to give you some tips on creating great storytelling for your testing projects.
First of all, check out Cem Kaner’s work on Scenario Testing: An Introduction to Scenario Testing. I want you to pay special attention to the CHAT (cultural, historical activity theory) model that he talks about. For more on CHAT and testing, read this paper: Putting the Context in Context-Driven Testing (an
Application of Cultural Historical Activity Theory).Pay special attention to the descriptions of networks of activity, and tensions. These are vital to help construct variations and different forces within our storytelling. Both of these pieces are foundational and worth the effort to dig into.
Now, I want you to read Hans Buwalda’s article on Soap Opera Testing. This is a nice variation on scenario testing. Buwalda uses television soap operas as inspiration for a story arcs, for structure, and for variation. Remember, there are lots of variations on a theme in testing, as well as real life! Further to that, look into testing tours. Cem Kaner has a blog post with a link or two to help get some background info: Testing tours: Research for Best Practices?.
Soap Opera tests, Testing Tours and Test Scenarios are a great place to start creating good testing stories.
Next, read up on personas in user experience work. Jenny Cham has a really nice description, with lots of helpful links on creating personas here: Creating design personas. Remember to explore her links in this blog, she has great advice here. I wrote a position paper about using UX personas in testing years ago (I will have to dig it up, there’s a dead link) in this blog post. Elisabeth Hendrickson introduced me to this idea, but she recommended using extreme personas such as cartoon characters. I prefer the standard UX methods pioneered by people like Alan Cooper, but the cartoon or other characters are a great place to start, especially if you feel stuck. Personas are a great way to start developing characters for your story that are relevant. What are their motivations when they use our software? What are their fears? What are their cares and worries and distractions?
Next, I want you to read this piece on telling a great story by a famous author: Kurt Vonnegut at the Blackboard. (I am getting to the gamification side of this project, and I asked Andrzej Marczewski for good references on storytelling in games, and this was the first link he sent me. Thanks Andrzej!) Notice the different options for structuring a good story. In testing, we can use different ones for the same scenario, if we think about activity patterns, tensions, characters, and variations during real life product use. Several versions of one story will yield different kinds of important information and observations. Vonnegut provides a simple framework for story creation that we can easily adapt and apply.
Finally, I want you to look at story telling in games. Andrzej talks about it here: I want to experience games not just play them. Notice that within a game context, of a well designed game, he has a sense of cause and effect: decisions made here can impact things in other areas of the game. That’s just like real life, and it is important to add dimensions to storytelling in games for testing. Variation and dimensions have different effects in a system, and they are rewarding to exercise. Now read this piece on Gamasutra The Designer’s Notebook: Three Problems for Interactive Storytellers, Resolved by Ernest Adams. The points about character amnesia, internal consistency and narrative flow are pure gold for testers. We often arrive into a system without really knowing what is going on, especially at first. However, our customers are also starting from scratch when they use our app for the first time. These problems are areas we should also address when creating stories to test around.
There is also a lot of really useful information here: Environmental Storytelling: Creating Immersive 3D Worlds Using Lessons Learned from the Theme Park Industry by Don Carson, particularly with regards to environmental conditions being so important to incorporate (particularly for you mobile testers!) and the idea of an all-encompassing world, rather than one, linear story.
Andrzej also recommends reading Uncle Computer, Tell Me A Story, and Story Structure 104: The Juicy Details.
As testers, we can incorporate more than a linear scenario into our work. We can add so much more depth to our test approach using stories and worlds. Story development in games is incredibly similar to the story telling we need to do in testing. There is a lot to be learned about creating virtual worlds and stories within them to help change our perspective, explore variations and make important discoveries about the software and systems we test. We can leverage these various works that have been provided with us to create something new and powerful.
Some final points to put this all together:
I have compiled several foundational concepts to help influence your storytelling, so now the rest is up to you. How you combine them to create something useful is up to you and your team. You have an opportunity to create rich perspectives to kickstart your testing efforts.
Happy storytelling!
I love to see creative work from people in the industry, and Martin Jansson always impresses me with his insatiable desire to learn, to do better and to take risks with ideas to push the craft forward. While I have been looking at gamification lately, it was exciting to learn that he and his colleagues had already been applying some of these ideas by looking at storytelling and games, and using some of those ideas to add more fuel to test idea generation during exploratory testing work.
Cem Kaner’s work on scenario testing is a powerful approach to testing. This is an approach to quickly create useful testing scenarios and ideas where we create a compelling story about the people who use our software, describe typical usage, possible outcomes, and human activity patterns surrounding usage. One of the most interesting outcomes of this kind of work is that it puts us in the role of our end users, and helps us quickly identify problems that they are likely to encounter. It also helps us understand when our software actually delivers, we can tell project stakeholders that our software works within the narrative of real-life scenarios. So not only do we uncover important problems, we also provide information that validates what we have done. “Yes! It works in an emergency scenario we didn’t think of during requirements definition!”
There are a lot of ways that we can frame scenario tests to provide structure and help with creative test idea generation. Using gaming as an influence, Martin Jansson and Greger Nolmark wrote a paper on adding structure to scenarios during exploratory testing sessions using storytelling as a guide:
Exploratory Test Adventure – a Creative, Collaborative Learning Experience.
I got excited when I started reading this paper because any kind of creative structure that we can add to test idea generation helps us be more thorough, and helps create more and better ideas. As Martin says, “…by setting up scenes, just like in a roleplaying adventure (or RPG game), you and your testers will have an increased learning experience that lets you explore beyond regular boundaries, habits and thought patterns.”
I often lament that testing information focuses too much on the negative, when we should also tell stakeholders when the team has done a great job. As a designer and programmer, sometimes I get worn down by constant criticism and ask the testers to also give me some positive feedback along with the criticism. After all, critiquing isn’t all about the bad news. It sometimes feels hopeless if all we get is the negative, with no positive feedback at all. Testers on the other hand, often feel like they are failing if they don’t find bugs and provide consistent negative feedback. But if we look at a story, some of them have happy endings. They have twists and turns and there are negatives, but there are also positives. Both are important factors to a story or game (or else they are too sappy and silly if it is all positive, or too depressing if they are all negative) and they are also important factors for determining whether a product or project has merit, or if we are ready to ship. Storytelling is one mechanism we can look to to help us get beyond mere bug hunting, and to provide quality-related information, both positive and negative. This pleases me.
Check it out, it is another example of looking at game mechanics, and applying one gamification aspect to software testing to help us make testing more valuable, more effective, more creative, and hopefully, more fun.
I decided to analyze a game feature, the “quest“, which is used in popular video games, particularly MMORPGs. Quests have some compelling aspects for structuring testing activitues. Jane McGonigal‘s book “Reality is Broken” provided me with a solid analysis of quests, and how they can be adapted to real life activities. Working from her example of a quest (ch. 3 pp. 56) , I created a basic test quest format:
A quest is larger than a single testing mission (or a test case), but is smaller than a test plan. It’s a way we can organize testing tasks to help provide a sense of completion and interest, but in areas that require exploration and creativity. Just like in a video game, there are multiple ways to satisfy a quest. Once we have fulfilled a quest, which might take days or hours, depending on how it is created, we can move on to another one. It’s another way of organizing people, with the added bonus of leveraging years of game design success. Furthermore, modern technology involves a lot of collaboration between people in different locations, using different technology to reach a common goal, and we need to adapt testing to meet that. Testing a mobile app in your lab, one tester at a time, won’t really provide useful testing for an app that requires real-time communication and collaboration for people all over the world. MMO’s do a fabulous job of getting people to work hard and co-ordinate activities in a virtual world, and people have fun doing it. I decided to apply it to testing.
Where do quests fit? Think in terms of a hierarchy of activities:
A good test approach will have more than one model of coverage (check I SLICED UP FUN for 12 mobile coverage models), and under each model of coverage, there will be multiple quests. Sometimes quests will be repeated when regressions are required.
So why add this structure?
One area I have worked on over the years is using structure and guidance to help manage exploratory testing efforts. In the past, test case management systems provided some measure of coverage and oversight, but they have little in the way of intrinsic value for testers. People get tired of repeating the same tests over and over, but management love the metrics and they provide even though they are incredibly easy to cheat with. Furthermore, from a tester’s perspective there is an extrinsic reward that is inherent in the design of the tools, and they are easy to use. There is also a sense of completion, once I have run through X number of test cases, I feel like I have accomplished something.
With exploratory testing, the rewards are more intrinsic. The approach can be more fulfilling; I personally feel like I am approaching testing in a more effective way, and I can spend my time on high value activities. However, it is harder to measure coverage, and it is more difficult to direct people in areas where coverage is required without adding some guidance. There have been a lot of different approaches to adding structure to exploratory testing over the years to find a balance. Test quests are another approach to adding structure and finding that balance between the intrinsic rewards of pure exploratory testing, and the extrinsic rewards of scripted testing. This is an idea to provide a blend.
As many of you have heard me argue over the years, test cases and test case management systems are merely one form of guidance, there are others. In the exploratory testing community, you will see coverage outlines, checklists, mind maps, charter lists, session sheets, and media such as video demonstrations and all sorts of alternatives. When it comes to managing exploratory testing, one of the first places we start is to use session-based testing management. This approach helps us focus testing in particular areas, and provides a reviewable result, which makes our auditors and stakeholders happy. I’ve used it a lot over the years.
I’ve also used Bach’s General Functionality and Stability Procedure for over a decade to help organize exploratory testing. However, through experience, unique projects and contexts, I have adapted and moved away from the orthodoxy where I saw fit. However, when I started analyzing why people on my teams have fun with testing, SBTM and Bach’s General Functionality and Stability Procedures were big reasons why. Even though I often use a much more lightweight version of SBTM than he has created, people appreciate the structure. The General Functionality and Stability Procedures is a great example of guidance for analysis, exploration, and great things to do as testers.
The other side of fun on the teams I work on are related to humour, collaboration and technology. We often come up with nicknames, and divide up testing into teams and hold contests. Who can come up with the best test approach? Who recorded the best bug report video? Who found the most difficult to find bug last week? What team has the most pop culture references in their work? Testing is filled with laughter, excitement and learning, and some good plain old fashioned silly fun. We communicate constantly using technology to help stay up to speed on changes and progress, and often other team members want to get in on the action. Sometimes, it’s hard to get the coders to code, the product owners to product own, and the managers to manage, because everyone wants in on the fun. In the midst of this fun is incredibly valuable testing. Stakeholders are blown away by the productivity of testing, the volume of useful information produced, the quality of bugs, and the detailed, useful information from bug reports to status reports and quality criteria that is produced. While there is laughter and fun, there is hard work going on. I learned why this is so effective reading Jane McGonigal’s work.
In Reality is Broken, Jane McGonigal describes Augmented Reality Games (ARGs). These are real life activities that are gamified – they have a game-like structure applied to them. She mentions Chore Wars, and how gamifiying something as mundane as household chores can turn it into a fun activity. She mentions that since cleaning the bathroom is a high value activity in the game, her and her husband have to work hard to try to clean it before the other does. McGonigal explains that since there is a choice, and meaning attached to the task, people choose to do it under the mechanism of the game. It’s not that awful thing no one wants to do anymore because it is unpleasant, when framed within a game context, it is a highly sought after quest or task to complete. You get points in the game, you get bragging rights, you get intrinsic rewards as well as the extrinsic clean bathroom. Amazing.
If we apply that to testing, how about using lessons from ARGs to gamify things like regression testing, or test data creation, or other maintenance tasks we don’t like doing? One way we can do this is to sprinkle these tasks within quests. You can only complete the quest by finishing up one of these less desirable tasks.
In Reality is Broken, McGonigal defines a game as having four traits: a goal, rules, a feedback system, and voluntary participation (pp.21). Working backwards, in exploratory testing, a lot of what we do is voluntary because testers have some degree freedom to make decisions about what they are going to test, even if it is within narrow parameters of coverage. Furthermore, we can choose a different model of coverage to reach a goal. For example, I was working with an e-commerce testing team who were bored to death of testing the purchasing engine because they were following the same set of functional test scripts. To help them be more effective and to enjoy what they were doing, I introduced a new model of coverage to test the purchasing engine: user scenarios. Suddenly, they were engaged and interested and found bugs they had previously missed. I then helped them develop more models of coverage so that they could change their perspective and test the same thing, but with variation to keep them engaged and interested while still satisfying coverage requirements. As humans, we need to mix things up. Previously, they had no choice – they were told to execute the tests in the test case management system, and that was the end of it.
Feedback systems are often linked to bug reporting systems in testing. But I like to go beyond that. Bring in other people to test with you in pairs, trios or whatever combination to bring more ideas to the table. This isn’t duplicated testing, but a redoubling of brain power and effort. I also utilize instant messaging, IRC, and big visible charts to help encourage feedback across functional areas of teams.
Rules in testing are often related to what is dictated to us by managers, developers, and tradition. It boggles my mind how many so-called Agile programmers will demand their testers work in un-Agile ways, expecting them to create test plans, test cases and use test case management systems. When I ask the programmers if they would like to work that way, they usually say no. Well guess what, not many other homo sapiens like to work that way either. I prefer to have rules around approach. We have identified risks, and models of coverage to mitigate those risks, and we use people, tools and automation to help us reach our goals. Rather than count test cases and bugs, we rate our team on our ability to get great coverage and information that helps stakeholders make quality-related decisions.
Finally, a goal in testing needs to be project-specific. If you want to fail, you just copy what you did last time on your test project. The problem with that is you are unaware of any new risks or changes and you’ll likely be blind to them. Every project has a goal, a way we can measure whether we did the right sort of work to help reach that goal, rather than “run the regression tests, automate as many as possible, and if there is time, do other testing”, we have something specific that helps ensure we aren’t doing busy work, but we’re creating value.
When it comes to quests, they can have this format as well. A goal, a feedback system, rules or parameters on where to test, and voluntary participation. As long as all the quests are fulfilled for a project, it doesn’t matter who did them.
It turns out that my application of SBTM, Bach’s General Funcationality and Stability Procedure, plus some zany fun and utilizing technology to help socialize, report and record information, I was right next door to gamification. Using gamification as a guide, I hope to provide tools for others who also want to make testing effective and fun. A test quest is one option to try. Consider using avatars, fun names and anything that resonates with your team members to help make the activity more fun. Also consider rewards for difficult quests and tasks such as a free meal, public kudos, or time off in lieu. Get creative and use as much or as little from the video game world as you like.
Some of my goals with test quests are:
I am encouraging testing teams to use this as a structure for organizing test execution to help make testing more engaging and fun. Feel free to add as many (or few) elements from video game quests as you see fit, and alter to match the unique personalities and goals of the people on your team. Or, study them and analyze how you organize your testing work for you and your teams. Does your structure encourage people to have fun and work hard at accomplishing something great? If not, you might learn something from how others have managed to get people to work hard in games.
Happy questing!