During the last 10 years, quite a large chunk of the developer community in Sweden have evolved with the help of Agile (and, recently, Lean). This means that almost everywhere you go, IT departments are inspired by this fairly new approach to development. And quite often people have implemented different Agile techniques in their processes, making the turnaround times smaller and collaboration better. But, in too many cases, people try to do "Scrum by the book", copying the methods and techniques without questioning, without adapting them to the situation at hand. I've seen many companies saying "Yeah, sure, we're doing Agile, we have our daily scrum every morning". You can probably guess where I am heading, just by reading the title of this rant, but before that I have another tale to tell...

The User eXperience community have, through the years since its birth, been wildly influenced by both cognitive psychology research and design (as in creative, graphic design in the ad agencies) as well as traditional IT methods. The psychology foundation has given the UX practitioners a firm method base to stand on, but (and I do say but) the ad agency heritage had made the UX practitioners heroes of design, working on their own, producing wireframes and other deliverables like magic. When UX:ers entered the old IT world of the waterfall method, this malpractice was enforced, it was easy to set up shop in the silo named "The Design Phase". This way of working was also taught in the human-computer interaction courses. I am not passing blame, only telling it as I actually lived it and taught it this way myself. Everything could be solved by just applying a bunch of techniques in a certain order, that was the message I used to preach.

Then combining Agile and UX should be as simple as shoehorning in the old UX methods into the Agile iterations, right? We'll just do our pixelperfect wireframes that we will deliver to the developers a bit quicker than we used to do. But, all that shoehorning only gives us blisters. Putting a lot of thinking in the design is needed, we have learnt that, to build the right product. The complexity of the analysis and design phases are high, there are a lot of things that needs to be set before we deliver what shall be implemented. (This is by the way also true even if we use an Agile method.)

So, we add a long Sprint Zero before the developers start implementation, thus going back to the waterfall-style design phase were we feel comfortable. We continue throwing documents over the invisible but oh-so-tangible wall. Some teams have found that doing design one sprint ahead helps, and it does, but it is still throwing documents, albeit smaller ones.

Going back to the Agile guys from the first paragraph. They too are trying hard to make the methods work for them in their setting. Their management are telling them to work faster to be able to deliver on a certain date. But things like on-time and on-budget delivery or even high quality aren't helpful if you've built the wrong thing. I guess I said that already.

But, isn't there another way of doing this, where we can keep the detailed design thinking but moving ahead quickly anyway? I believe that the actual problem stems from a misconception. The misconception that Agile is methods, processes and practices ... and nothing else. The Agile Manifesto exists, with its "We prefer [the left side statements] over [the right side statements]", but there is actually more. In my experience, people do not know that, so today I've taken on the role of the educator. I present to you, the 12 Agile Principles:

Scrum, Extreme Programming, Kanban and the rest of the Agile and Lean methods are actually frameworks. Frameworks with the purpose of upholding the principles. These principles shall lead the way to better products through things like better collaboration and motivated people. We have to understand why we are implementing a certain method. When we have understood that, we can pick the practices we see work towards the principles and for the specific product we are working on right now. So, following principles, working smarter instead of faster, will in the end make us work faster while maintaining depth and quality.

But to make sure that we are doing the right thing, we must constantly fight. It will not be enough taking a 2-day-long Scrum Master course to know what methods and practices are the correct one, we must constantly inspect and adapt. Our tool for that is 改善 - Kaizen, continuous improvement. If someone tells you that Agile is to have a Daily Scrum each morning, I can tell you they are wrong, but if they say it is to have a retrospective every week (and react on things said there), then they are on the right track. UX practitioners can use this tool as well, to adapt their methods (we really have a lot of them) to the agile ones. Inspect and adapt.

Through inspecting (reading about or discussing methods and trying them out in an agile setting) and adapting (them to the situation at hand), I have found a few principles that seems to work for me. They might prove a good starting point for you. My goal for these principles is to deliver actual value through collaboration, building on the Agile principles.

• Stop delivering deliverables, deliver value.
  
  User research and design that is continously communicated to the team and the stakeholders give a lot more value than a wireframe in a document. Use the Build-Measure-Learn-loop from Lean Startups to make sure that you are always on the right track instead of trying to validate only when the product is "done". You should always look at your product as a hypothesis that can and should be validated as soon as possible. Building a minimum viable product and throwing it away if it proves to be the wrong thing to build gives validated learning, and that is more valuable than anything else. Eric Ries argues that "Success is not delivering a feature; success is learning how to solve the customer's problem".


• Let go of the hockey rink boards and sketch early
  
  Short feedback loops. The quicker ideas are visualized, the faster you get feedback. Use pen and paper. Stay away from cumbersome Adobe products. Or as the Agile manifesto says: "Simplicity - the art of maximizing the amount of work not done - is essential." Be transparent. Put your sketches on a sketchboard and let everyone give their comments. Of course, you as a UX:er is the expert, your final decision is what goes into production, but all input is good input. Yes, the ice is slippery, but you can do it!


• Collaborate collaborate collaborate!!! (Paraphrasing Mr Ballmer)
  
  Create the possibility of collaboration everywhere. This will make you able to dig in deep, to iterate design as much as it is needed, but with a lot higher speed. Dare to step out of your silos. Pair design with developers, bring them with you on usage tests, involve everyone in the product team in a design studio-session where everyone can try out their ideas. The possibilites are many and should be taken. Everyone wants to work on something tangible, and what is more tangible than a mockup that you've built together. As a UX:er, you change role from being a design to become more of a design facilitator. This will build trust and team spirit. It's not only "developers developers developers", but they can be a lot of help in situations you'd never imagined.


• Get out of the building
  
  Meet actual users. Jeffrey Liker says, in The Toyota Way, "In my Toyota interviews, when I asked what distinguishes the Toyota Way from other management approaches, the most common first response was genchi gembutsu [go and see] [...] You cannot be sure you really understand any part of any business problem unless you go and see fo yourself firsthand." This should be a no-brainer for a UX practitioner, but we tend to do it in large scale and quite seldom. Have a "user-day" every week, even if you do not have anything apparent to test. It's worthwile just sitting down and talk for awhile. Don't make a big thing out of it, make it normal.


• Continuously improve
  
  I've given you examples of what works for me. Now, try it out yourselves. Inspect and adapt.

The life of a UX designer can often be lonesome, being the only person with that set of skills on the team or even in the company is not uncommon. You might sit totally by yourself in your own one-person-department or you might be part of a team, but working in silos.

When you are part of the team, you would think this would not happen. But the cross-functional team principle of agile is often thought to mean that every person on the team should be able to do everything to bring the product forward, i.e. producing code, and seemingly mitigating risk by being able to cover for each other. This usually means that the UX designer has to code (and hence contribute!) or that all coders together create some half-assed user experience during the development cycles based on a delivered wireframe. This is clearly not getting the most out of the development process to actually deliver value. If you are in this situation, it is time to collaboratively produce a user experience with your team mates that will give great benefit to the customer.

Leah Buley (of Adaptive Path) came up with a design method a few years back under the name of UX team of one. This method has been the foundation of my work since then and I can strongly recommend you to try it out. Its aim is to make sure that you leave your silo as much as possible, getting maximum feedback from your environment, but at the same time avoid the design by committee-problem. There are three phases in the method:

In my opinion, the easiest way to ideate is to work with a template. I use a 6up-templates to create (at least) 6 different possible solutions to a problem. The template consists of 6 small boxes on an A4-paper. The size of the boxes forces you to sketch roughly and not consider details. I decide before sketching if I am doing a spectrum design (6 different sketches ranging from what fits the beginner to what fits the expert, or any other characteristic on the axis), a graph design (2-dimensional) or a grid design (1 sketch per grid element). Sometimes I use the 1up-template to show the best idea in more detail so that it is easy to understand.

After I'm done ideating (i.e. creating a lot of different versions to a solution) I put the sketches up on a wall to create a sketchboard (shown as a yellow board in the method figure above) so that everyone can see them and give feedback. This sketchboard will also contain any other kind of information or notes about the design problem, such as the user story card, specific requirements and limitations, the persona that will use this solution, etc. The reviews of the sketchboard can take different approaches. Some people just like to discuss the sketches, some use post-its to write comments and on some occasions we use dot-voting to decide what sketches are good solutions.

The actual realization of the outcome from the sketchboard can be in any form, but I like to keep it fairly lo-fi and create prototypes in Balsamiq Mockups. These can then easily be tested with actual users and since they are still in low fidelity, the user dares to comment on them.

So, this method allows me to only deliver what gives value at the moment, such as sketches on a sketchboard for a feedback session. But, I am still working in my silo. Hence, I recommend using the collaborative Design Studio method for ideation.

The goal of Design Studio is to come up with a solid foundation for further design collaboratively in the team (where the team can consist of almost anybody, including stakeholders and developers). It can be broken down into 4 (or 5) steps.

1. Illuminate - In the first step, the team reaches a shared vision of the problem and set the boundaries. One way of getting there is to brainstorm about the current situation. To reach this understanding could take a long time. My opinion is that it is of outmost importance that everyone understands the situation, so let this part take its due time.
2. Sketch - Let everyone in the team (including you) sketch using a timebox of about 5 minutes in the second step. It is important that the sketching is quick, since giving people time gets them stuck on unnecessary details.
3. Present - In the third step, everyone shows their design in a short presentation, quickly followed by...
4. Critique - An open discussion about the design, meant to churn out the key issues and inspire the other members for the next sketching iteration. The critique should focus on the few most important parts of the design.
5. Iterate - Run the last three steps 2-4 times depending on how much time is left after step 1. Iteration is the key to finding reliable solutions.

The overall rule for Design Studio is to never dwell on details (with the exception of the illumination phase), to get most value out of the least amount of time. After a Design Studio session, I, the UX designer, have plenty of material to work with when returning to my silo.

_{More information about collaborative design in agile projects (in Swedish).}

People wonder what differs between what has been called Agile UX for a while now and the new kid on the block, Lean UX. My take on the question is that UX designers who have entered the agile community early have needed to define their own set of tools to work tightly together with the agile developers. Agile UX is all about collaboration. There are really no hints in the agile literature on how to incorporate UX. The UX designers in the agile teams have been caught in a frantic struggle to adjust their old tools and deliverables to whatever seems to fit in the agile environment. Meanwhile, the agile people have moved on (or the early adopters at least) from "old" agile methods such as XP and Scrum to Kanban and Lean methods. The new Agile UX methods of collaboration, such as cross-functional pairing and all-out team design studio sessions work in these new settings as well.

With Eric Ries' book Lean Startups, which has become a sort of bible in the hands of these early adopters, Eric takes the Lean approach all the way and explains how to focus on business value with the help of validated learning (build-measure-learn-loop), customer archetypes (personas), etc. This is easy for a UX designer to grasp and it brings a clear vision of what business value is. This is the base of LeanUX, which is focusing on validation. The practices in Lean UX are often called common sense, because for a UX designer it is, since we have been brought up on discussion about business and customer value.

Lean UX works in agile environments and that is only because Lean and Agile are closely related. If you are benificial to change (a lot of people aren't, especially some developers, and this is why Kent Beck's first XP-book, aimed at developers, is subtitled "Embrace change"), then it is not a problem slashing away at your own methods, killing your method darlings so to speak, to end up in something that would work in agile environments. But, overall, I feel that UX-people (me included) have always only talked about killing your method darlings, but never, as Jeff Gothelf phrases it, about "getting out of the deliverables business". Lean UX is all about finding out what actually delivers business value, not spending time on deliverables such as huge information architecture diagrams and unused wireframes. This still means that some things need to be thoroughly done, even if the agile environment do not think so, the things that gives actual value.

In the article about cupcakes, I try to explain how to extract business value using Lean UX methods.

As I wrote in the article Agile UX Roles, it is very important to have a broad set of competences to get benefit from the software produced in a project. The competences have to fulfill the Three Pillars of Innovation - Viability (business), Feasibility (development), and Desirability (design). The business analysts have to find out how profitable the solution is while the developers have to find out if they actually can build it and at the same time, the designers need to know if it is desirable enough. All of this together forms the value of the product. This value can in most projects be found over time, but at that moment it might be too late since the world out there is constantly changing. Naturally, it is really important to find out early if your product is what people want.

To many agile teams, this seems like an easy task. Incorporate the UX-guys into the team, make them follow the same methods, as I've written so many times. Just build it and test it. Instant gratification. But Anders Ramsay says (and so do I) that the UX designers' biggest mistake is to think that methods like Scrum or XP are synonymous with Agile. He argues that those methods were created by and for developers to solve developer problems and to create high-quality efficient software. That is one form of value, one form of quality, but not the whole story that makes the customer want to buy our product. We designers need to look towards what actually creates value in the long run, and with that, desirability.

Enter the Minimum Viable Product (MVP). In product development these days (and now I am talking about the business side) the MVP has emerged to find out if the customers are the least interested in a new product. A minimum viable product has the exact (not least) amount of features to make it desirable and sellable, thus giving value. It is created to maximize learning. The all too common approach to using an MVP is what Brandon Schauer calls a dry cake.

First, a cake is created, this is a product that has the minimal but complete usage flow with a minimal but complete technical framework. It is nice, it is a cake. It shows that the product is feasible. It might say something about viability, for instance showing the cost for the developers to add a feature. It might also say that the interaction design is good. It is easy to add filling (features) since we have both the design and the technical frameworks. Sales persons will probably argue that to make it sellable it needs this and that feature as well, adding items to the feature list on a daily basis. What is missing is the icing. So, somewhere along the line, we find what is the icing, what makes the product desirable and interesting, but as I mentioned earlier, this has taken way too much time. We need a better approach, we need to use a real MVP.

Let's start with creating a cupcake instead of a dry cake without filling and icing. The cupcake has filling and icing, but not so much compared to the cake. But, the cupcake is something that the customers want, need and love, so you can start measuring how much and if it is viable to produce.

After that you can easily expand your MVP to become a cake with filling and icing. And since you then know that you have a feasible, desirable and viable product, you can easily expand it to become a wedding cake. The only thing you have to remember is that less is more.

There is a confusion around the concept of user experience design (UX). Everybody has their own meaning to the expression. The current Wikipedia definition is in my opinion cutting right to the chase:

User experience design is a subset of the field of experience design that pertains to the creation of the architecture and interaction models that impact user experience of a device or system. As user experience is a subjective feeling, it cannot actually be "designed". Instead, you can design for a user experience, trying to enable certain kind of experiences. The scope of the field is directed at affecting "all aspects of the user’s interaction with the product: how it is perceived, learned, and used."

Based on this and on discussions in the UX community, I think the general consensus is that user experience is the umbrella term that encompasses a wide array of interface-related fields. The three biggest fields are information architecture (IA), interaction design (IxD) and usability (and most organizations see visual design as a big part of UX as well). The figure below separates the areas by focusing on which methods and techniques that are most commonly implemented by a certain role.

As a UX designer or as a part of the UX design team, you need to be both information architect, interaction designer and usability engineer, and sometimes also a graphic designer or art director.

• The information architect role is often described as the librarian of UX. It involves a lot of categorizing and organizing the content of the system. Methods like card sorting and search engine optimization are often used.
• The interaction designer role, quite often also an interface designer, concerns all aspects of a user's interaction with the system, its behaviour and crafting a workflow that covers all aspects of this.
• The usability engineer role, focuses on methods for user research and usage testing, both with and without users, to provide insights about the system. Another big part (or side) of usability is accessibility, i.e. focus on people with disabilities and their right of access to the system. This role tends to be less creative than the designer role, aligning on measuring and modelling.

All of these roles are obviously overlapping, both in time and in methods. The figure above is not showing a comprehensive list, e.g. information architects and interaction designers should of course do usage tests as well, but they usually focus on other methods.

Some people have other fancy titles, such as usability expert, UX architect or interface rockstar. These architects/experts probably do a lot of high-level, strategic work related to UX. A designer will probably be more hands on in implementing the actual interface solution itself.

Regardless, everybody in the UX area should do user-centred design, i.e. incorporating the user into the development process. To accommodate that, everybody should have a cognitive science background to be able to really understand the user and his/her needs and limitations. Otherwise, we will never know if we are doing the right thing and doing it right.

thesis

When gathering information from stakeholders in a project you usually end up with a lot of functional requirements (as in "You shall be able to save your drawing in a PNG-format") and some semi-functional ones (like "The drawing shall be stored in a database"), as well as some non-functional ones (for example "The system's latency when loading a drawing from the database shall be low"). These latter ones tend to come from stakeholders with a technical perspective, but these non-functional requirements are obviously quality aspects of the system, and so is usability. Thus, the quality 'usability' should have an equal place in the requirement documentation as the other non-functional requirements. But, what subqualities of usability are there?

The answer to that question is simple and at the same time somewhat complex; any adjective that users may use to describe their interaction with the system is a subquality to usability. If the user wants the system to be snappy, then a corresponding usability quality might be quickness or swiftness. One could argue that this is the same quality we spoke about above from a technical perspective, i.e. latency. But, latency is the exact (timed) response from the system and quickness is the user's perception of this response. For instance, if a call to a not-so-well-designed database would take 30 seconds (high latency), then giving the user appropriate feedback during this time will get the user to rate the quickness as fairly high. Not giving feedback, on the other hand, would get a really low quickness rating. (In effect, this means that a good design can make a bad system look better, and a bad design can make a good system look worse.)

If you feel that the users might not be able to express different qualities, then you can use already set subqualities. The most famous set is hidden in the ISO definition of usability (i.e. in ISO 9241-11). It specifies the "extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use". The qualitites being effectiveness (task completion), efficiency (task in time) and satisfaction (user's experience).

In practice, usability goals are often created to make the qualities more general. Contemplate the example below (from Hackos & Redish^[1]), where a more specific expression from the user is written in broader terms.

These kinds of goals can be used as project goals (where they are sometimes called effects), as sprint goals or milestone goals, or simply serve as focus for a design.

But if we make them measurable, they can be what makes your usability process legitimate in a world of non-believers. You can for instance measure efficiency by the time it takes to complete a task, by judging the percentage of the task that was completed or the number of times the interface misleads the user.^[2] What works best is up to you. Below is another example from Hackos & Redish^[1], this time of how a usability goal can be translated into a measurable objective.

But, you usually end up with goals that require a user's subjective opinion. You can probably not tell your superior at work that the users thought that the product was fairly nice to use, you have to be a bit more precise than that. I usually go with a five- or seven-point Likert scale as in the example below:

I would not recommend using a ten-point scale, because that would give the users too many alternative. And in Sweden, since we have a special word that means "just enough, not too little, not too much", in some occasions I would go for a four-point or six-point scale, not to make it too easy for the users to pick the middle one.

In an ordinary project I would start out by running a contextual inquiry with the users working in the current version of the system or a competitor's, and afterwards try to create usability goals from the needs and requirements that they express. Then I would create measurable objectives from these usability goals and ask the users about their feelings about the current system (or measure time/errors/etc. during an observation). This will set a baseline for the project. During the design and implementation phases, I use the usability goals for focusing my design work and the sprints, as well as using the measurable objectives when testing out mockups and prototypes. I sometimes use the measurable objectives as definition of 'Done' for agile stories, as well.

When using the Effect management method, the usability goals (and their measurable objectives) are the core for everything created in the project, and the results from the method are steering the project. In the example below, a baseline has been set and the business owner has decided what would be the level to reach for the effect to happen.

Afterwards, when the product is finished, I use the goals and objectives for usability validation. Below is an example of how my colleagues and I summarized the usability validation results, including some statistics, in a document for executives just before product launch:

I am certain that there are other ways to use these goals and objectives. Do drop a line in the comment field below if you know of other ways to use this. And by the way, here are some more examples of measurable objectives presented by Usability.gov.

Now that I have shared my knowledge concerning usability goals, please share yours in the comment, especially if this small article has helped you in any way.

^[1] Hackos, J.T. & Redish, J.C. (1998). User and Task Analysis for Interface Design. New York: Wiley & Sons.
^[2] Pär Carlshamre - A usability perspective on requirements engineering

• Domain knowledge (the original Product Owner)
• Developing and architectural skills
• Design skills (especially UX)
• A vision of the product's future (and perhaps the whole product range)

This skill set will probably not fit in one person's head, thus requiring a Product Owner Team. Jeff Patton argues that there should at least be people covering the following three areas comprising the team:

Patton explains that to get benefit from the software, it must be used (usable/desirable), cost effective (feasible) and give value back to the business (valuable). This means you need to incorporate business concerns in design decisions. So let's add one more bullet, one more role on the list of people in the Product Owner team that shall have:

• Business perspective (perhaps in the form of a Business Analyst)

This is often mentioned in the role of information architect, and it might fit there. In my opinion, the business perspective requires greater focus and a better overall view. A role in traditional project containing this perspective might be the one of the product manager.

For large applications and product ranges there might be several Product Owner Teams, lead by a Super Product Owner or such a Product Manager mentioned above. This hierarchy is quite common for the developer teams, calling the supergroup a Scrum of Scrums.

In this picture three teams are supported by one Scrum Master each, and the Scrum Masters have a Scrum of Scrums team together with the Project Lead. Equivalently, there can be a Scrum of Scrums team with the Product Manager and a Product Owner Team for each developer Team.

So, let's focus on the UX person's responsibilities in a Product Owner Team. They are:

• Creating measurable product goals, i.e. effects. When I discussed The Effect Backlog, I used the example of a hotel that wanted to attract more customers. A measurable goal for that could be to get 50% more customers in a month.
• User research leading to personas. This is work done that will contribute in a great way to the whole product line. An investment for the future, and as being such, it might be that user research should be done continuously outside the project. The first set of Personas, though, should be simplistic to help you learn what you know now and what you need to fill in later, to get the project going.
• Creating measurable usability goals, to attend to and measure the user's perception of the system's usefulness. A usability goal from the hotel example was that the customers/users should feel safe when staying at the hotel. A measurable, although perhaps unachievable goal could be that 100% of the customers should say that they feel safe.
• Creating the actual effect backlog. The UX person should write full epics, with user needs and context in them. This is to make it easier to tie the whole project together after it has been divided into smaller chunks/stories and implemented.

These epics usually consist of a sentence describing the problem in short, on the form of As a [stakeholder], I want [feature] so that [benefit]. The UX person's job is to get more substance into the [stakeholder] and the [benefit] parts. The persona constitutes the former part and the usability goal the latter. Apart from this, every epic should have some kind of basic interface sketch connected to it, since communicating with pictures AND words gives the best understanding. This is to avoid writing a detailed design document. Also, specifying acceptance criteria, what is the definition of 'Done' for every epic, should also be the UX person's responsibility. Most of these epics could have an acceptance criteria corresponding to the measurable usability goals and/or the effect.

The epics can also be used for creating high-level scenarios (for design sketching or usability testing). The easiest way of doing this would be to combine stories (the [feature]-part for a certain user/stakeholder) into sentences, using conjunctions to connect them. An example:

As a hotel guest, I want to feel safe during my stay, so I use my personal keycard to get into my room and use the extra latch to lock the door as well as the ordinary lock.

For lower-level scenarios, to be used as functional requirements or similar, use stories instead of epics.

Other tasks for the UX person involves evaluating spikes with users to investigate the implications of new technologies and of course prioritizing the backlog, which is a constant task.

When the system is released and goes into operations phase, the job for the UX person is not finished. To ensure that the general usability of the system isn't degraded over time, there is a need to continuously measure the effect and usefulness, especially in an environment where other people are responsible for adding and removing content (e.g. a website with a news page).

That concludes this article and like all the methods and techniques I write about, it is all contextual. This might or might not work for you. Please tell me in a comment below how you incorporate UX in an agile project.

An acquaintance of mine asked if there was a twitter client for the iPhone especially made for seniors. He used twitter to update the world about his family's life. His father, an 82 year old Swede, had recently gotten an iPhone, but all twitter clients had too many functions and were in English. I did not know of any so I set out to create one myself.

As a Usability Designer, I naturally use user-centred methods to reach a good enough design. The ISO 13407 is a good framework to use for achieving quality in use of a product. The framework is based on iterative design and thus one can perform different activities for each iteration to solve the current design problem in that iteration.

It is common to use a plethora of techniques for each phase in the iterative UCD cycle, such as focus groups, depth interviews, expert evaluations, wireframes, card sorting and personas. For this small project, I chose the quick and dirty version.

Context & Requirements
To understand the context of use and to agree on the requirements, I created a scenario for the senior users to review and give feedback on.

The scenario acted as a starting point for understanding what the users wanted to get from the project. The users read it and contemplated on it. Then we together discussed and refined what such an application would look like. The outcome of this discussion was a design.

Solutions & Validation
A good idea is to create a first design that the users dare comment on. A first design that displays a high fidelity and great face validity often make the users say "Oh, fine, are you finished already, great!". Instead, I usually start out with hand-drawn sketches, also known as low fidelity prototypes or simple mockups. These can be displayed after each other and explain the flow through the application. Using them while following a scenario such as the one above is sometimes called a cognitive walkthrough. Such a walkthrough aims at finding bottle-necks in the interaction as well as issues with the interface itself. The user steps through the scenario using the prototype as a full implementation, using his/her imagination and faking the parts of the user interface that are not yet implemented. This gives a very real evaluation of the application, without the need for implementation.

In this sketch, Arne is the senior user and Tomas is his son who has the Twitter feed. The users could easily identify with Arne and could give feedback directly on the sketch. One comment on this sketch was that the possibility to reply to a post was unneccesary and thus, in the name of simplicity, it was removed totally from the interface. Another comment was "what about pictures of my grandchildren?". A new version of the prototype was made, one with higher fidelity to be able to discuss design issues on a more specific level. This was swiftly created with OmniGraffle.

The second evaluation, done in the same manner as the first one, found some issues that would have been hard finding with only a low fidelity prototype, such as the clarity of the text on the screen. The choice of colours and the bubbles were not popular amongst the senior users with less than great visibility. Another comment was that there was little need for an update button; it is better to restart the application since this follows the users' mental model.

After this session, the design was ready to be implemented. For you who are interested in how it was implemented, the backend is a simple PHP-parser for the Twitter user's RSS-feed. This version requires the tweets to contain a link to a twitpic for the image handling to work. The frontend was made with HTML5 and CSS3 with iPhone Webkit-specifics.

This first actual version aimed at maximizing visibility. Apart from adding the date, a feature that was missed in the earlier designs, a new feature was added; the possibility to zoom. Two old fingers on a slippy display is much harder than just turning the device 90 degrees.

One last evaluation was made before releasing the application to its intended target group. This evaluation just corrected some minor issues and the full application can be seen on the designs page. All this was just a few days' work and the web application was ready in time before Christmas.

This was a simple way of implementing a UCD method for a single designer/developer. This article ends as a lot of other articles on this site. Always contextualize your method and add what works for you today!

Scrum Primer
Scrum is focused on the planning and following-up parts of a project. Three roles are specified for Scrum: The Product Owner, the Scrum Master and the Team. The Product Owner is the voice of the customer, this person (or team) has the domain knowledge and the mandate to decide what will be built. The Product Owner is in charge of the Product Backlog, which contains both the plan and the requirements (features to be built, etc.) for the project. The Scrum Master is in charge of making sure that the team follows the Scrum rules and stays agile. This person is an ordinary team member but has great process knowledge and acts as a coach. The Team is a cross-functional group of people tasked with implementing the requirements.

Each iteration in Scrum is called a Sprint, and this sprint usually lasts between 3 and 5 weeks. In the beginning of each sprint there is a Sprint Planning meeting, where the Product Owner presents a chunk of the Product Backlog that he or she would like to see built at the end of the sprint. The team estimates the chunk according to their knowledge and skill, and makes sure it will fit during the sprint. Once the team and the Product Owner have agreed that they have a well-sized and meaningful chunk of features to build, which is called the Sprint Backlog, the team builds it (supported by the Product Owner for requirement details). Each day during the sprint, a very short project status meeting occurs. This is called the Daily Scrum. During this meeting, each team member answers the questions: What did you do yesterday? What will you do today? What might hinder you from doing that today? The reason is to keep everybody up to speed and solve difficult problems as soon as they arise. At the end of the sprint there is a Sprint Review meeting, where the team shows their built chunk and the Product Owner gives feedback. This feedback might then be a part of the Product Backlog and put in the Sprint Backlog for later sprints. After the Sprint Review, there is a Sprint Retrospective meeting where the sprint is analysed and the team can adjust/improve/correct their process before the next sprint starts.

The team sprints until the Product Owner is either content or out of money. This requires each sprint chunk to be a potentially shippable product. To make this work there has to be some kind of rough plan as to what will (or might) be released to the Product Owner in each sprint. Hence, the team usually starts by building a foundation (as well as getting the process on track). This sprint is called sprint zero.

As with all agile methods, you are supposed to add to the method what you think is missing. This is why you often see Scrum combined with Extreme Programming in software development, but Scrum in itself has many other application areas. The following is what a combination between Scrum and user experience would look like.

UX Sprint Zero
For the user experience practitioner, the sprint zero should answer why the project shall be built (usability goals and effects) and who it will be built for (target groups, the customer, other stakeholders). This is well-taken care of using Effect Management in Scrum. Sprint zero should also contain some basic design, to get a good start in the following sprint. This design should be lightweight. This sprint zero is counted in weeks, not months. In a single week of collaborative design, one should be able to sufficiently understand the project objectives and the high level functional scope so that the the size of the project can be roughly estimated and a sprint release strategy can be formulated. It is the same here as in pair programming, two heads think better than one, and you will get automatic quality control of your ideas. You should end up with a rough overall design for the project. Since Scrum is running in iterations, this design will have to be split up in parts that can be designed, built and validated somewhat independently.

If the project is large, break it down and do parts in different agile teams. It is still possible to have only one or two UX practitioners, even if you have two or three teams.

UX Sprint Planning
Since the UX practitioner is tasked with creating usability goals for the project, this also applies to the sprint. This is done together with the Product Owner, who should create a general sprint goal for the sprint. The usability goals will help the team in estimating how long it will take to build each feature.

Creating low fidelity prototypes (mockups) which easily may be brought to a tester, stakeholder or user for informal usability tests gives optimal feedback given the time invested.
If such mockups of the design exist, it will greatly aid the team's estimation task, since a visual explanation helps understanding than the more formal requirement from the backlog. Also, alternative solutions can easily be discussed and dealt with swiftly using prototypes.

UX Sprint Running
For each sprint, it is not necessary (nor is there time) to create more than the before-mentioned prototype, since there is time set aside during the sprint for communicating details. But exactly how this takes place can be discussed. Here are two suggestions how to handle the communication between UX practitioners and developers during the sprint

• Plan ahead
  
  Here, the design and the development are seen as two parallel tracks. The developers run their course as before, and for them to be able to do this, there must be enough designed of the user interface before the start of the sprint where the feature is to be built. This demands that the sprint zero is somewhat deeper than mentioned above or that the first sprint for the developers mainly consists of non-GUI features. In reality, both of these statements are required, since UX design penetrates further down than just the user interface.
  
  
  
  
  Additionally, as shown in the figure, the UX practitioners are one or two steps ahead all the time in this method. While the developers implement design, the features from the last sprint are being usability tested, and at the same time, the research and design for the following sprints are done. The advantage of this approach is the added time for research and design compared to the following suggestion, and this is the reason this might work better for some people.

• Incorporate design sessions
  
  And for other people, this approach might be more suitable. In this approach, the detailed design is done in cross-functional design sessions during the sprint. This gives time in sprint zero for deeper research (such as a better detailed sprint release strategy) that pays off later as well as time during the sprint for basic design for later sprints. When a UX practitioner is a team member, this basic design time will be accounted for during the sprint planning.
  
  
  
  The design sessions themselves work as following: A session is the start of the building of a feature. It requires the whole team including the Product Owner and UX practitioner (as well as at least a tester), to give everyone in the team an understanding of the design and an appreciation for the process and tradeoffs necessary for a good design. The group designs the GUI together, in as much detail as possible. The rest of the details follow generic platform guidelines, i.e. do not dwell on pixel-specific issues unless they really make an impact on the user experience. The design session is timeboxed (depending on the size of the feature), from 30 minutes to about 4 hours. For a well-defined increment of the product, i.e. a good sprint backlog, it is possible to do a longer design session for all of the GUI design of the features at the start of the sprint.

This last suggestion is advantageous since it gives more time for usability testing and quality assurance during the sprint. This testing can be done when a feature (or a set of features) is finished, but the recommendation is to do it the last week of the sprint. Then you test all the features that have been built so far with select users. In parallel you may run an informal pre-validation test (depending on how many testers and user representatives that are available) since this gives a lot of good input to both usability QA and to the product owner before the sprint review meeting.

Apart from all of the above, do not forget to try adding what works for you today.

Scrum

Using the method Effect Management (by InUse) creates a good base for the Product Backlog in Scrum. The method steers the project towards the expected effect (or the user experience) of a product, using a five step method and four key concepts: Effect, usability goal, target group and action.For example, a hotel branch would like to make more money, i.e. get more customers. This is the expected effect. To achieve this, they would have to convey different feelings to attract the customers, like being classy but at the same time affordable and secure. This is a usability goal. So, when creating the main entrance for the hotel, you would of course like it to function properly, i.e. open inwards to let customers in as well as open easily outwards for panic situations, as well as welcoming the customer and ensure his/her safety. This is the action. This has to be tested to ensure the effect, with real customers. This is the target group. And of course, this target group helps with finding the usability goals and the necessary actions to fulfill the goals as well.

Putting this into the five-step method: Firstly, describe the expected effects. The description should contain how to measure the effect, otherwise it is of low use. Secondly, clarify the user's goals. Translate the user's goals into usability goals and measure them. Thirdly, create possible solutions (i.e. the action) to the usability goal. The easiest way is to create some kind of prototype. Fourthly, test in actual use, otherwise the effects will not relate to the actual situation. Especially if you test with a prototype, try to do it with actual users where they would use a real solution. And last, visualize all of this in an effect map, it will be a lot easier to track changes and understand correlations.

It is widely spread amongst Agile practitioners that, while describing what to do in a backlog item, it is a good idea to explain why this has to be done. This is where Effect Management fits. Combine the effect mapping that we did above with the common format for a product backlog (and replace Description with Action, as well as adding whatever columns you usually have). It might look something like this (in your spreadsheet application of choice):

As an example, from the beforementioned Product Backlog-link, the first item in the Product Backlog is Finish database versioning. Using the Effect Management method, this description (or action) would be explained/motivated by the corresponding usability goal. At the same time, it would be easy to understand which users that would benefit from this backlog item and what effect this backlog item would have on the software in the long run.

An even better approach is to write user stories on a slightly different formats, so that every story on the agile board will show for who the feature is created, why it is good for them and why it is good for the company.

For the whole Agile team, it would then be a lot simpler to estimate each item as well as easier to understand how and why a certain item is prioritized the way it is. This user story will then truly guide the development towards the right product. It's a win-win situation since UX practitioners also like to connect actions (i.e. production code) to usability goals (and effect), e.g. for easier validation or usability testing.

Scrum

The Agile Manifesto values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The problem areas have traditionally been the same in design as in software development. A focus on processes, documentation, etc. has prolonged (and sometimes ruined) the project. In many kinds of projects, adapting to agile methods (which means implementing the above-mentioned principles) has proved successful. But how do you apply them to user experience design?

In a waterfall-like project, you have room for a lot of analysis, a lot of design and hopefully also a lot of testing. The simple approach is to scale down everything you're used to doing. This can be enough for the product you are designing, but there might be a constant struggle to explain designs, keep up with the developers, and actually be able to test anything before release. To solve this, you'll have to adapt the methods to agile principles and the time-frames of agile projects. If you ordinarily do deep interviewing and Visio-style interface specifications, you will probably need to change the method to something less time-consuming, like time-boxed group interviews, cross-functional collaborative design sessions, as well as swiftly created mockups (on paper or with Balsamiq) actually constituting the specification. Also, instead of using a complicated setup for usability testing with many users, do a small-scale test (while recording with Silverback) using Guerilla HCI methods.

Apart from lowering the fidelity of your design and adapting your methods, you need to position yourself in the project to achieve a productive agile UX environment.

You need to have mandate in deciding what is built as well as the overall business strategy, the effects of the product. Create a map that visualises how a design can support the envisioned effects, supported by user stories and prototypes. This map can then also be used to roughly estimate the size of the project, as well as helping developers to estimate tasks. A suggested approach for the agile method of Scrum is described in the second article.

At the same time, make sure that you synchronise your design work with development, i.e. integrate your usability methods in the development method and be a part of the team. It is possible for the UX practitioner to act as customer to the agile team (or be part of the Product Owner team in Scrum), but communication and design would benefit more from a closer integration. You would then have a better involvement in the final result and the chance to learn from the developer's knowledge. A collaborative design approach can help you being and staying agile; having continuous discussions about the design instead of detailed specifications will support the core principles of agile methods. In the third article is a suggestion of how this might be achieved in Scrum.

To summarise, start thinking and start acting agile. It will be productive and fun.

A common way of separating users with the intent of forming different target groups for usability testing is to use age as a variable, for example in a user cube. The problem is that this is of course a tricky variable to use. Usually, we aim to define end-user populations as homogeneously as possible, since it is then easier to do user testing and optimize user interface design. This approach is good as long as the product is intended for professional use, by users who are between 18 and 50 years old. This approach was good enough twenty years ago when most computer programs had that target group. Today the situation has changed. Target user populations have become heterogeneous, with people of all ages using computers more or less on a daily basis and more or less successfully. Two outliers in this distribution are children and the elderly. Digital natives are a large user group and the computer literates has become twenty years older as well.

During these two periods, adolescence and senescence, the changes on a cognitive level and the differences between individuals are great. The former period we call development and the latter, for lack of a better word, decline. For example, you have probably heard about both precocious kids and late bloomers. A uniform age group is not applicable, hence it is important to have usability professionals taking a deeper look at user group compositions when developing for the youngsters and elder people of today.

I once carried out several projects involving both these outliers and became very intrigued by developmental psychology, especially the parts focusing on children. This article will focus on the theories behind and will try to give you some heads-up before you conduct usability testing with children.

^{© MrsGooding}

One theory of cognitive development of children, which seems to be the most common, is the one of Jean Piaget. He divides childhood into four development stages; sensori-motor period (infants), preoperational period (2-7 years), concrete operational stage (7-11 years) and formal operational stage (11 years and up). Although the timing may vary, the sequence of the stages does not, thus this theory is a good base for differentiating target groups of children. The characteristics of the preoperational period is a development of an inner representation of external objects. The thought processes of the child are then linked to the most prominent features of an object or a situation. The concrete operational stage is characterised by logical and purposive thinking, although the operations are always connected to the actual situation. In the formal operational period the children disengage from the concrete situation and become able to perform systematic analysis on an abstract level.

Apart from standard interview techniques such as commencing the interview with smalltalk, there are some issues to take into consideration when interviewing children that I learned during the aforementioned projects. One such thing is considering the attention span of the child. A session with young children demands a flexible setup of the evaluation. The child should be able to explore the product almost on their own instead of following a set of tasks. They are often motivated by making adults happy, hence let them show what they have found in the product and increase their motivation by encouraging them. For example, say "Wow, did you do all that by yourself?" or "Is that how it works! Thank you for telling me!". Furthermore, avoid placing the child in front of the interviewer, place the child in front of the product with the interviewer acting as support on the side. In one of the projects, four male interviewers in their early twenties sat down in front of an eight-year-old girl and were surprised when she didn't want to cooperate in the evaluation. Apart from steering clear of these kinds of situations, it is a good idea to have younger children evaluating in pairs where they can encourage each other and share ideas. It is also easier for them to speak about the product with a peer than with an adult.

This shyness towards adults is most visible in the preoperational stage. Hence, children in this stage can also have problems with expressing their feelings for the product in words, especially in front of a grown-up. Observe their behaviour, sighs, smiles or if they simply disappear under the table (which occured a lot with some children). Also, try to avoid asking the children if they wish to play a game or perform a task as this will give them the option to say no. Instead, say "Now, I would want you to..." or "It is time that we...". This is easier to do with children in the concrete operational stage.

Children in the concrete operational stage have a high tolerance for complex interfaces. They employ pattern-based problem solving, "push twice on the left button and three times on the right button to reach the gold" comes natural as long as it benefits them. They are starting to understand how to critically review the task given to them. They will be able to answer questions regarding the task and try new approaches with joy, but they are very aware that they are being observed. The previously mentioned eight-year-old asked the interviewers, in a latter session, why they wanted her and not her sister to evaluate the product. When the session ended it seemed as if she only criticised the method and did not care about the product. Later on, her teacher collected some drawings of hers containing references to the product and it was accompanied with a sun and a couple of green trees. Some children would like to answer questions orally and other in writing, but remember not to neglect those who want to express themselves with pictures.

In the formal operational stage, children might be able to think aloud while they are performing a task. However, what has to be taken into consideration is that these pre-teens or teens are not geniuses that can adapt to every complex situation. The possibly bad performance of the teens are caused by mainly three factors; inadequate ability to read, bad research strategies and a relatively low level of patience. There are simply a lot of other things happening in their world at that particular moment that we unfortunately have to contemplate.

On the other hand, most children tend to be smarter than you would give them credit for. One eleven-year-old girl demonstrated her own Klik & Play-made programs to the interviewer and explained how she could make the product in question smarter. The outcome was, needless to say, very appreciated by both parties. Children understand the concept of usability. Most children in the two operational stages can spot the difference between fun and efficient. They are as motivated by reaching their goals as adults are, and they really do not like when a product is not working.

Jakob Nielsen has also taught us that we only need to test with 5 users^[3], but which 5 would that be? If we combine the user cube with this, and add something I call boundary user, we can add another dimension of the categorization that actually helps us in finding users that may help us best with testing a system.

The four boundary users are picked out since they are in the outskirts of the main group, hence they represent typical categories. Complete the user group with the one in the middle (another extreme point) and you get a five-user group that represents the two dimensions in the example above very well. For more dimensions, add more boundary users (another 4 for 3D, etc.).

^[1] Faulkner, X. (2000) Usability Engineering, Palgrave
^[2] Nielsen, J. (1993). Usability Engineering. Academic Press.
^[3] Nielsen, J. (2000). AlertBox: Why You Only Need to Test With 5 Users

Mr. Alexander

The solution just lay there and stared at me. Think abstract! Usability is an iterative method, and so are agile methods. So instead of seeing them as two different tasks, the combination is quite straightforward. I removed the wall (with a little help from Eric Idebro & Illugi Ljótsson) and the solution presented itself:

The combination requires that in the first iteration (or 'sprint', as in Scrum) you only do usability tasks. A small specification with rough sketches and flows are presented, but they're still based on interviews, etc. This is good enough for building a foundation. If this would be Scrum (and from now on we assume it is), this first sprint takes about 3 weeks, and the conceptual design will be a part of the product backlog as well as the tasks for achieving the usability goals. This makes it easier for the developers to recognize usability as important work.

Then, during 4-week sprints, usability tests are conducted about once a week. Although this is somewhat demanding (the architecture must be good, probably a three-tier architecture), the input you get will drive the design in a simple way. To do this in an easy and straightforward way, the sprint is divided into four smaller iterations. In the beginning of each iteration, something small is built that is testable with users, a part of the GUI and some functionality perhaps. The results are put in the sprint backlog (and you have planned for that on the sprint meeting), and change requests are dealt with the following week. This is for steering during a sprint, and you do it by refactoring your usability design. Quite complicated.

The work for the interaction designer during the sprint is to produce test cases for the usability tests, and of course, conduct these, while doing GUI design. For every test phase in every iteration, you'll need real users. It is usually hard to find users and with this combined method you burn out users even faster, but on the upside there are enough test sessions to last for a lifetime.

At the end of the whole sprint, a full usability test on real functionality is done, the results of this test are discussed with the product owner, and will perhaps end up in the next sprint.

To work this way, there are some musts:

• The developers have to be interested in usability
• Continuous integration has to work really good. You have to deploy each week instead of each month.
• The product owner needs to know what user-centered design is, apart from just Scrum.
• The developers can't be junior usability specialists; It would probably be too demanding since you need to refactor the usability as well as doing everything else at once.

But you can always try!

I understand that this is only the beginning, but it is a rough plan. I believe that for every project you have to adapt the method to the circumstances.