I’ve been watching two trends recently in the realm of digital product development. First is the incorporation of gaming concepts into products that seemingly have nothing to do with gaming. Second, the importance of designing products that are not only easy to use but a pleasure to use.

To be sure, these trends aren’t new. My point is not to shed yet more light on what we already know. Rather, the potential impact of these trends as they go mainstream is significant for UX designers– our skills are becoming strategic rather than tactical.

Let me explain. A wireframe is a tactical output that (hopefully) partially fulfills a strategic direction for a system. But working with a product manager to figure out how to incorporate gaming concepts into a product moves us, the UX designers, in a strategic direction. This changes the opportunities in front of us as designers. The term I use to encapsulate these opportunities is “digital product strategy.”

What is digital product strategy?

Product strategy binds business strategy to product management. Marty Cagan put it nicely in a April 2009 blog post: “Think of it this way. The business strategy and business portfolio planning provides a budget and a set of business metrics. The product organization then lives within that budget to pursue as aggressively as possible the best ways to hit those business metrics.”

Product strategy (let alone digital product strategy) is a relatively unused term – no Wikipedia article exists as of yet, and it ranks fairly low as a competitive keyword (at least as I write this). As such, there’s not a lot of consensus as to what it encompasses. So, I’ll provide my thoughts with an emphasis on products that are digital by design – they make heavy use of software as part of their interaction model or delivery mechanism.

To me, a good digital product strategy brings together seven areas of expertise:

1. Market/industry expertise: A deep understanding of the domain you are engaged with;
2. User expertise: Engagement with actual or potential users of the product;
3. Competitive expertise: Commitment to finding “sustainable differentiation” – the “secret sauce” that cannot be easily copied;
4. Related-Industry expertise: Engagement with other industries or markets that you can learn from to create a better product for your industry
5. Design expertise: knowing how to make a product easy and fun to use with the latest design techniques for many different devices
6. Technology expertise: Knowing what is technically possible today and in the future and the devices that make sense
7. Business expertise: Knowing how the product will fit into the operational realities and capabilities of the business

Here’s an example, I have been working with a customer over the last few years to help them introduce a direct business-to-business channel alongside their traditional distributor-based model. The main channel became an e-commerce website, and our “product strategy” was about achieving parity with two main competitors. From a digital product strategy perspective, the website became the primary delivery mechanism for a tangible product, and thus a huge part of the product UX.

As we emerged from the parity phase, we consciously moved to an innovation phase. What once appeared as “solutions” in the first phase – an e-commerce website – looked like a limitation when we focused on the market and the users from this new perspective. Customers were using the website during lunch hours, and we knew that they were walking from the storage cabinet to the PC with written notes about what they need to restock. These two things pointed to a fundamental inconvenience in usability. This inconvenience couldn’t be fixed by a more usable website, however. It was a great opportunity for a mobile application with a bar code reader for replenishing inventory.

Had our product strategy remained focused on the website, we would have run repeated usability tests to fine tune the features, and we would have continued to focus on competitors to keep up with new features. The idea of a mobile app that really addresses that fundamental inconvenience wasn’t possible until we shifted our perspective. By combining our knowledge of the market, the users, existing technology capabilities, and design expertise, an innovation became imaginable. A new product is conceived that can move into the more traditional product management processes.

Product Strategy and User Experience Design

The example above points out how UX design is a strategic skill. As the realization of business strategies become more dependent on the development of digital products (or products that make heavy use of digital technologies), the UX designer offers the unique combination of:

1. How to understand the real life of users;
2. The capabilities of technologies and devices;
3. How to make something easy and fun (or at least really convenient) to use—three of the seven areas of expertise I described above.

This moves us closer to business strategy and simultaneously requires a change in our deliverables. In an earlier article, I discussed how the requirement is a “somewhat strange and antiquated way to capture what a software system is supposed to do.” We have to develop new deliverables to replace the requirement as the first and best way to express the system we want to design. Conceptual wireframes, sketches, storyboards, and user models (like the famous Flickr model) are more appropriate deliverables for product strategy work. Companies that consciously do product strategy as a discipline know this, but there’s plenty of opportunity left in the mainstream projects many of us work on each day.

As such, we supplement the work of the CTO, whose job is to set a technical direction. Martha Heller describes this role well: “… the digital product groups hire a CTO, who designs and executes against the digital product roadmap.” In other words, the CTO is the technical expertise part of digital product strategy, while UX design is the easy-and-fun-to-use part and the knowledge-of-real-users part.

UX Design, Product Strategy and Gaming

A new opportunity exists for the UX designer as gaming concepts become part of product strategy. Who else is better equipped than the UX designer to bring this discipline to the table?
To decide that a product is going to be structured as a game rather than, for instance, a document sharing system is a strategic product decision, not a tactical one. When we start thinking about incorporating gaming concepts into our products to increase engagement, we’re making fundamental decisions about our products.

A lot of people are talking about gamification of digital systems. I could choose any number of people to quote about the fundamental structures of good games and how they can be applied to digital products. I like the succinctness that Jane McGonigal provides, so I’ll use her definition: “When you strip away the genre differences and the technological complexities, all games share four defining traits: a goal, rules, a feedback system, and voluntary participation.”

There are two conclusions to draw from this for UX design:

1. These are not simply features we add into our digital products; they invite us to think about our products in a fundamentally new way;
2. The UX designer is the best equipped discipline to bring the full force of these concepts to the product strategy conversation.

Blending these traits into an engaging and compelling UX – that is fundamental to the product itself – is really what the UX designer is equipped to do. That companies are now getting on board with the engaging power of gamification in formerly utilitarian software systems yields lots of opportunities for our once tactical discipline to become strategic.

With sun, sea, and a tropical 30 degrees C outside, no wonder people kept  saying that UXLX felt like a vacation. You might think it a pity to be indoors. Luckily day one of the conference kicked off with some cracker material that justified staying inside.

Storytelling for User Experience – Whitney Quesenbery

One of the first workshops of the day was kicked of by Whitney Quesenbery. In her workshop she tried to teach the audience the importance of telling stories during the design process, both to clients and team members. One of her main messages is that stories aren’t a broadcast transmission, but always create a connection between the audience and the storyteller:

• the storyteller shapes the story;
• the audience form an image;
• the storyteller and the audience affect each other;
• the most important relationship is between the audience and the story.

When a UX designer did research and shares his knowledge with the team stories can be a great way of doing this. When done right the storyteller retells the important parts of the stories the users told him, thus creating a connection between the design team and the user.

In order to become good storytellers we first must learn to become active listeners. We need to really be willing to hear the story people (users) are telling us and understand what’s it all about. Being an active listener means we have to encourage the story to be told further, by asking open questions and giving non-verbal feedback.

During the workshop Whitney actively involved the audience by giving several tasks. She focused on the following subjects:

• Story structure: structures give the story a shape and help the listeners/readers to understand it better. Is it a me-they-me structure, do you want to turn it into an adventure structure or should it be a contextual interlude? The way you set the story up can help engage people in the right way and lay focus on the right part of the story (like the product, the user or the process);
• Story context: context grounds the story in a specific place and time. You may want to emphasize (or change) the location, time, history or something else to help the listeners to understand it better.
• Purpose in UX: stories help drive UX work in several different ways. Do you want to share a success story and share what made this product so great or is the focus of your story to facilitate a brainstorm and do you want people to think in a different context?;
• Format of the story: there are many ways to tell a story, you can decide how. Is it written or drawn like a comic? Should it be a formal presentation or a light conversation starter?
• Imagery: imagery gives the story emotional resonance. By adding details about the sounds, smell or motion of the environment or a specific person you can pull the listeners into the world you are creating.

These tasks were closely linked to the book she wrote with Kevin Brooks called Storytelling the User Experience., so if you want to know more I would definitely check it out (also check out our excerpt). All in all it was a very interesting workshop with loads of stories. And as Whitney said: “what is design but a story?”

Become a UX Team of One – Leah Buley

UXers may know about being asked if you’re an innie or an outie, but if Leah Buley’s research catches on, you might also be a giraffe, bee, beaver, or penguin. Confused? They sum up the types of people that might be described as a UX Team of One. In her interactive and workshop with a lot of new material (such as I can’t find pictures of the gorgeous icons she used for each animal), she took the group through planning their futures, and thinking about ways to combat issues as the lone UXer.

However, her outstanding and memorable takeaway (including beautiful icons sadly not caught on camera but bound to end up on badges) was that of the four types of UX Teams of One. She sees them as a spectrum (most of us start at number one and move down), and classifies them as the following:

1. The Crossover (giraffe) has recently come over from another field. (Their long neck is from foresight).
   As their challenge relate to focus, access and skills, the strategies are to do with collaborating and DIY research. A key point to remember is that clients won’t allow for research do it should just be built in or ‘done on the sly’ (our podcast with Sam Lader on design research also talks about this).
   Some methods include using MAYAs Heuristic Markup, The Five Second Test, and competitor images (even getting the clients to collect them as homework!)
2. The Doer (a bee) is a knowledgeable person in a company without a UX department — they usually have to do things beside UX or move departments a lot. As they are held back by being brought on too late, or not valued, they need strategies to focus on professional relationships, visibility, and ROI.
   Some relevant methods included Liva Labate’s UX Health Checkup, product definition workshops (stakeholders repeatedly draw and disucss their product vision, as after a couple of rounds they’ll be far more aligned) and “Lunchtime UX” listening dates with other key team members.
3. The Builder (beaver) has been in UX for while on point of starting UX team.
   As their issues relate to relationship management and politics, the strategies are to align with business and build out a team. Methods included ongoing internal surveys, case studies and pre-meetings (1-to-1 reviews of docs with each key stakeholder before a key design review)
4. The Independent (lonely penguin): those that are freelance etc. Literal team of one
   They need to promote themselves, be legally savvy, and set their own terms (e.g. using a project brief). What’s more, they need to be known for something (as Leisa Reicht has blogged about).

Buley has been evangelising the UX Team of one for a few years now, but those who saw her talk a while ago (or looked at the slides) should definitely see it again as there is a whole lot of new information in preparation for her book-in-progress of the same name.

Skeuomorphs: The Good, The Bad, and the Silly – Andrew Watterson

Skeuomorphism is the act of using cues from the old to make new things feel more familiar. It has been applied for a very long time and can in our practice be a great way to introduce people to new technology and interactions. Some of the better known examples of skeuomorphs are the sound of digital cameras when you take a photo and the fake engine sound electrical cars make so that you can hear them approach.

When launching a product with a totally new way of interacting, like the iPad, you see that skeuomorphism can be an easy way to let people get used to the device. Watterson gives examples like the bookshelf in iBook and the old fashioned look of the contacts page. But at the same time he points out that there is still a lot of debate whether this approach is really the best way to go. There are a lot of people who have strong opinions for or againts, like our writer Rahul Sen is the recent article ‘The IxD Bauhaus: What Happens Next?’  I believe that there is a balance and that skeuomorphism can definitely be a good thing, but that we should always try to keep challenging ourself to also look at different ways of approaching the interactions. It’s just one way to reach what we want, but surely not always the only and best one.

Watterson’s conclusions regarding to this topic:

• Use skeuomorphs to add a satisfying and nostalgic emotional effect;
• Bridge gaps between what people are used to and a new method with skeuomorphs;
• Question whether you’re skipping the opportunity for innovation by using a skeuomorph;
• Don’t mismatch your functionality with a skeuomorph.

Picking your Neurosurgeon’s Brain— Susan Dybbs

For most of us, the closest we get to seeing what happens in an OR is through TV shows. However Susan Dybbs showed us not only what a surgeon sees when they’re carrying out telesurgery, but how we can use participatory design methods to understand highly expert and tacit processes.

Starting with Terry Winograd’s observation that designers have limited time to process things like how something feels like is in the tacit domain, Dybbs pointed out the issues that designers have when trying to create interfaces for highly expert systems such as telesurgery interfaces — the designer can’t get anywhere near the understanding that the users have of what happens and what is working. She resolved this by reating a toolkit of a mockup process with clipping (words, chunks of information, pictures of xrays etc) and then got surgeons to talk/make through their experience of surgery.

One of the most interesting insights from this method was being able to show the difference between what users say they need and what they actually use. In the case of surgeons, this might be documentation that is for legal reasons but never used in actual surgery, information they didn’t actually need (surgeons thought they needed to see the room view but actually didn’t) and vice versa (e.g. sideness — which side of the body you’re operating on, is a minor but key piece of information in helping a surgeon orient themselves with telesurgery).

Her tips for best practices:

• Create a toolkit (nothing is more scary than a blank piece of paper)!
• Do your research (sort original themes)
• Precondition your participants (e.g. photojournal, or just storytelling/pre-interviews)
• Keep it rough + impermanent
• Think aloud (helps show mental models)
• Be flexible (e.g. meet people at their comfort zone — help them make collage if they don’t want to do it).

Creating the Ultimate Experience: UX + CX + CRM — Stuart Cruickshank

Can you have a relationship with your oven? Stuart Cruickshank argued that you could. How? Through a combination of acronyms: UX, CX (customer experience) and CRM (customer resource management).

CRM has traditionally looked at strategy, business, and technology, but thanks to social media, a new branch of this known as Social CRM has emerged that also looks at engagement and conversation through empathy, emotion, authenticity, transparency. A great example of a company using social CRM is Zappos — their model means that their customers have a great experience and feel empowered, while the company gains advocates and profit (they have no marketing budget!)

On that oven? The Art Home Electrolux project attempts to do this (an exciting restaurant in Paris uses all Electrolux products, and the cook provides tips about cooking, meaning the customer could go home and cook what they got at the restaurant, as well as continuing the conversation through social media.

After a lot of conferences talking about service design, it was refreshing to have an alternate take on service systems UX could get involved with. As Cruickshank pointed out that the end of the talk, while CX and CRM have more visibility at the corporate level, at the end “experience is the goal”.

For those interested in the topic, he highly recommends Paul  Greenberg’s CRM at the Speed of Light (4th Edition).

Effective Design Documentation Without a Fuss — Dan Brown

Despite the growing interest in living prototypes for UX, it looks as if design deliverables won’t be going away any time soon. Dan Brown (who we interviewed earlier this year) tried to trick the attendees into saying it might be or otherwise, but most UXers know to always say “it depends”!

What is design documentation? Brown defines them as “an artefact, defined by a team, to create a project, whose purpose is to move a project forward.”

He suggests that many designers forget to think about purpose and progress (at worst making some projects stand still), as above all, documentation should inspire action.

Brown breaks down design documents into different types: clarifying approach, justifying decisions, comparing multiple approaches. Each of these should be handled differently, just as your structure should change if you’re writing for a different audience (e.g. developers vs C-level).

He finished up with a look through the Eight Shapes Unify system he took part in creating. His rationale for the system is that most existing templates in Word etc are a waste of time as they force you to fill in blanks.

The best takeaway in regards to writing was to “be a journalist not a comedian” — in other words summarise first rather than having it at then end (common in comedy but in journalism known as burying the lead).

Designing by Doing: Bringing Agile Thinking to UX Practice – Anders Ramsay

Agile development is one of the hot topics in todays UX scene, so several talks at the conference today focused on this topic. In Anders Ramsay’s workshop he didn’t jump into the agile process itself, but used the approach of agile thinking and showed how we as designers can use it in our day to day practice. He did this by giving several tasks:

• Paired interviews: this method comes from paired programming, where two programmers sit behind one screen and together write the code. In paired interviews you let two users interview each other instead of you interviewing them one by one. According to Ramsay this is a great way of getting insights you would normally be unable to collect, since the users themselves know what to talk about and what is interesting to know. By letting them conduct the interviews and write down the interesting material you can collect great amounts of raw data in a short time;
• Agile personas: in agile development you don’t design all the details at once and you try to minimize the amount of documentation. The idea behind agile personas is to create very light-weight artifacts out of research data (like you collected through paired programming). By letting the entire team check the raw data and detect trends you are able to share with them important insights. When you after that write the agile personas (real name, main characteristics and quotes) you have a great starting point for your future discussions;
• Story flows: use some of the user stories you collected in your user research and prioritize them. After this you can start adding tasks to each story and prioritize these as well. Even when you are not doing scrum you can still use story flows to get a good overview of what you want to create and especially what’s the most important thing to do first.

Ramsay’s workshop was very engaging, although a bit chaotic. He was well able to show everybody the power of agile thinking, although there are still so many other things to agile thinking that would have been worth sharing… one of the aspects I find most interesting is the daily standup with the entire team, to get a good feeling of what the current progress is. You don’t need to scrum to have the benefits of this way of working together as a team.

As an interaction designer working in an Agile environment, I’ve recently been asked by several colleagues in non-Agile arenas – folks in agency settings, consultancies, or in-house software companies – what it’s really like in terms of design workflow and output. Their questions have touched on everything from the day-to-day differences to the quality of the designs coming out of the process, and their perspectives have ranged from casual-and-curious, to scared-and-skeptical (e.g., “Oh, it’s just a fad” and “There’s that vast Agile agenda again.”)

Well, that got me thinking. What were the real differences, anyway?

The Agile Agenda

Two years ago, I was brand new to Agile software development and pretty naive overall when it came to understanding competing development methodologies. These days however, I feel like I have some ground beneath my feet when talking about development processes and their underlying philosophies. In taking a step back to consider what it has really meant for me as a designer these last couple of years, I tried to tackle questions like:

• What am I doing now that’s different?
• Did my previous skills and user-centered design approach still apply?
• Did I need to learn anything new?

And, perhaps most importantly:

• What has the overall quality of the user experience really been like?

The following takeaways capture some of the things I’ve learned along the way. This is simply my perspective with a little insight on what the transition has been like. What it is not, is a guide for what you and/ or your team of designers should be doing. I’ll leave that to far more knowledgeable folks to chime in on. Besides, one of the major tenets of Scrum is to do what makes the most sense for you and your team.

one of the major tenets of Scrum is to do what makes the most sense for you and your team.

(Note: It’s probably helpful to at least have a rudimentary understanding of Agile Software Development at this point. Check out the Wikipedia entry to learn more.)

Designer as Design Facilitator

First, a little context. One thing that Agile newbies should understand is that the importance of the team and its dynamics are paramount. Scrum teams are small, self-organizing, and cross-functional. They should include representatives from design, development, and quality assurance. Work is committed to for a finite period of time – known as Sprints, which typically range from 1 to 4 weeks – and the team takes on a feature(s) that it feels it can deliver in that amount of time. And “deliver” does mean working code that is technically releasable to the masses.

I work very closely with the developers on my team and even co-locate occasionally. That in and of itself isn’t ground-breaking stuff. However, what I’ve found is that a large part of my job these days revolves around continually fostering communication within the team, as well as with peripheral stakeholders.

A large part of my job these days revolves around continually fostering communication within the team, as well as with peripheral stakeholders.

Since the focus of the team is to consistently work on items that deliver the most value to the customer, distinct roles within the team are sometimes blurred. Everyone contributes to the best of their abilities given the priorities, including providing input on design. This is especially true when it comes to new features with undefined requirements, but it really has to do with the intimacy of the team and the immediacy around the thing that we’re working on.

Let’s say a Product Manager gives the go-ahead on Feature X because she sees a glorious market opportunity. Once that is communicated to the team and prioritized within the backlog – basically a to-do list consisting of “user stories”, which are written in non-technical language to describe the value of a feature from a user’s perspective – it is up to the team to decide exactly what to create. The product team may still have the final say, but it’s up to the designer to lead the early efforts. That includes applying the tools of her trade in the way of user-centered design principles, coupled with a clear understanding of the business drivers and the technology behind it all. Although some of you reading this may be saying “Well, I’ve been doing that all along, anyway”, the difference here is that it is now being recognized. More on that later, though.

When we embark on a new user story, one of the first things I do is generate some ideas and hold early brainstorming sessions with my core team. This allows me to corral the different ideas and understand everything from technical feasibility, to ballpark estimates on the potential development work involved. Sometimes the conversations go astray or become focused on implementation details, so it’s my job to get them back on track by grounding everything in the end users’ goals and expectations. And everyone likes to be heard, so there’s a good deal of diplomacy required as well.

This ongoing dialog helps to ensure that we as a team are headed towards an appropriate solution and it’s these conversations that the designer needs to facilitate, time and again. (By the way, all of the above involves getting user feedback early and often, but as designers reading this article, you already knew that.)

Again, the headline here is that it’s all about the team. Designers don’t design in isolation and then simply hand-off a design, never to be heard from again. It’s a much more collaborative and tightly integrated effort between the designers, product management, developers, and of course, users.

Nimbleness Required

OK, so all of the above assumes that a Designer actually has the necessary time to conceptualize, validate, and then iterate accordingly. Unfortunately, that’s not always the case with Scrum and this is one of its downsides; which, by the way, is also frequently cited by its critics – especially in the way of shortcomings related to being truly innovative.

When done properly, a “Sprint Zero” is introduced to allow designers to do their upfront discovery ahead of any coding. However, given the flexibility inherent in a process that is beholden to shifting business needs, priorities for the team do sometimes change from Sprint to Sprint. That allowance is, of course, one of Scrum’s key value propositions. It’s also where being nimble on the part of the designer needs to come into play. The old-school way of having a rigid, stepwise process doesn’t apply terribly well any more for delivering complex software that is useful, usable, and ultimately timely. Design processes need to adapt to some degree as well.

All of the above however, doesn’t mean that design thinking isn’t valued; it’s just that designers need to be flexible and shift priorities in accordance with business objectives. If you’re a designer that finds themselves deeply committed to a design or unable to let go of a particular project, you’ll need to acclimate. Designing within Scrum means being able to shift as needed and handling ambiguity well. Really well.

Designing within Scrum means being able to shift as needed and handling ambiguity well. Really well.

(For more on the pros and cons of incorporating User-Centered Design within Agile, do read Anthony Colfelt’s incredibly insightful article).

The Lovely Bones

As mentioned earlier, Scrum understands that the needs of the business and its customers (i.e., requirements) will change and almost embraces that mantra. However, because Scrum also calls for working code as soon as possible, you may be thinking that those are opposing forces at work. However, the truth is that it can work. And once again, this is where our fearless designer comes in…

Remember Feature X and how the designer was brainstorming what it could ultimately become? Well, if we join our regularly-scheduled programming already in progress, it’s the designer (and potentially researchers) that are coming up with the building blocks for an incrementally feasible strategy.

What are the core features that users need? Which functionality can they live without (for now)? What could add some wow-factor? In other words, what’s the Minimum Viable Product (MVP)? Getting user feedback is crucial at this juncture to help determine what the bare bones will be – sometimes referred to as a “walking skeleton.” Designers help define what gets released in order to then get feedback on what’s working, what isn’t, and what’s next. To a large degree, releasing often tends to keep your designs and product honest.

Designers help define what gets released in order to then get feedback on what’s working, what isn’t, and what’s next.

As with any process, there are very real trade-offs involved. Given Scrum’s inherent proclivity to release something sooner than later, the big question often becomes “is it good enough?” This is why designers working in Agile need to be well-versed in communicating the business value of good design. Making business folks and developers understand why user experience matters is critical to the success of your product in this environment and it’s a never-ending crusade.

Incremental Design While Keeping Your Eye on the Prize

In working to define a Minimum Viable Product, the first challenge is thinking through what can be built in order to satisfy marketplace and user needs in the here and now. Again, we’re back to that notion of immediacy.

Because a designer goes from defining high-level requirements to specifying the very concrete steps of what to build and when, the trick is to keep your eye on the big-picture. I’ll have to admit that I’ve found this to be one of the most challenging aspects of designing in this environment. Once you determine what to build as bite-size pieces of functionality in order to get something out, it becomes increasingly difficult to keep a systems-level perspective on the holistic user experience – i.e., trying to avoid a Frankenstein-ish product – when priorities shift and you have to come back to a design at a later time.

Take any great iPhone app as an example. It doesn’t include everything-and-the-kitchen-sink, but instead distills the core set of features that users will need and then attempts to make that experience really good. This doesn’t mean that you can’t add or improve things at a later time; it’s just that you try and give customers the best you can with the bare essentials first. (One could even argue that the entire smart phone revolution is founded on this very principle. Otherwise, users would have surely dismissed the complexity inevitably inherent in designers lazily porting over a desktop experience into the mobile world.)

Welterweight Documentation

It’s probably no surprise at this point that design documentation is kept fairly minimal. The close working relationship among team members means a great deal is communicated face-to-face via sketches, whiteboards, and simple wireframes. The goal of design work (i.e., creating deliverables in the way of experience models, flow diagrams, and mockups) is really to communicate ideas to the team so as to jump-start the development process.

Once developers begin coding, I make sure to check-in early and often to offer advice and provide any additional documentation, repeating as necessary. Documentation still exists and is important, but it’s kept lightweight to capture the essence of an interaction and consumed in a just-in-time fashion.

For those designers coming from more traditional development backgrounds, you may be relieved that large documents with incredibly detailed specifications, footnotes, and obscure corner-cases, are a thing of the past. However, as indicated above, the time you have to think through a design is also compressed.

The big takeaway here is to use your design time wisely and create only as much documentation as is absolutely necessary to communicate your ideas effectively. It doesn’t need to be pixel-perfect, unless of course it needs to be pixel-perfect to get your concepts across.

create only as much documentation as is absolutely necessary to communicate your ideas effectively

Retrospective Introspection

When was the last time you really thought about what you and your team were doing? Did you ask questions like: How is this process going overall? What’s working and what isn’t? Should we be doing things any differently?

Well, with Scrum, facing yourself in the mirror is a standard option courtesy of “retrospectives” after each and every Sprint. They offer the team an opportunity to acknowledge strengths and weaknesses with unabashed transparency. I’ve found that the very nature of this exercise forces designers to focus more on what’s important by continually questioning their own process. This is especially beneficial when it’s coupled with customer feedback from designs that are live because the team is getting stuff out more often.

facing yourself in the mirror is a standard option courtesy of “retrospectives” after each and every Sprint.

Parting Shot

Hopefully you now have a little insight as to what to expect with Agile, as well as some awareness of the trade-offs involved. Upfront design and research are sometimes rushed and the ever-present threat of compromising user experience quality in favor of releasing something – which frankly feels like a gravitational pull sometimes! – are very real challenges. That said, not going astray and loosing your moral and/ or design compass by building unnecessary features and going down dead-ends is ultimately a good thing.

And rest assured designers, there’s still no shortcut to delivering a great user experience. The same, core user-centered design principles you know and love still apply and are highly valued. In the end, it’s not that drastic of a shift and designing within Agile just keeps you on your toes a little more.

My parting advice: be nimble, collaborate with your team as much as possible, and don’t take an uncompromising, hard-line approach to process guidelines. And most importantly, keep your eye on the prize.

This is the first of a two-part series. The second article, Designers as Product Owners, will focus on additional responsibilities designers can take on within an Agile organization.

Collaborative design methods play a key role in aligning team members towards a shared and strategic project vision. In this article we describe how user stories stimulate and facilitate discussion and decision making with clients in the development of a User Experience Strategy. In our context (the development of online projects) the User Experience Strategy becomes an ‘in principle agreement’ on the shape of the project (what), its purpose (why), and provides potential implementation strategies (how). It takes into account all perspectives (e.g business, technical, marketing, brand) but privileges the intended user experience.

A collaborative approach enables clients to actively participate in the process, increasing the likelihood of achieving a collective vision for the project. This article focuses on the first step in the journey towards collaboratively developing a User Experience Strategy and is concerned specifically with how user stories are generated, themed and prioritized. Interested in more? We will be talking about this subject at UX Australia 2009 at the end of this month.

Background

Working agency side, our involvement as User Experience professionals in a project often starts after the client has already invested in developing initial project assets. These might take the form of requirements, objectives, user profiles, user research or feature lists for example. There might also be pre-existing content or collateral if an existing site or service is being replaced.

While this information goes some way to describing the future project, it does so via the different agendas of marketing, technical, business, or brand; each asset takes a different perspective and is presented in its own ‘language’.  These different perspectives can effectively point in different directions, making a holistic view of the project difficult. It can also mean stakeholders hold different visions of project outcomes. Engaging in design at this point means risking significant tensions and costly delays down the track.

Different perspectives on the project.                           Different agendas impacting in the design phase

Reframing the project

By collaboratively developing a User Experience Strategy with clients, we can create a shared and holistic vision for the project that guides us through the design phases of the project. Central to a User Experience Strategy is the perspective of the people who will actually use the Website. Part of developing the strategy is re-framing the project from a user experience perspective.

Looking at the project from a client perspective

Looking at the project from a users perspective

The client perspective often starts as an abstracted, inside out view of the project via feature lists and technical specifications.  A user perspective on the other hand looks at the project from the viewpoint of those who will use it. By re-framing the project in terms of the intended user experience we shift to this perspective. This perspective is necessarily more concrete because it forces us to take context into account. In order to effectively think through the project from the user’s point of view we must think though some of the variables of the situation in which it will be used. This is the role of tools such as personas and scenarios; they work to ground the project in the real world, ensuring we don’t design in a vacuum.

Creating user stories

User stories are collaborative design tools which help the team to think through what the project needs to deliver from the perspective of those who will use it. User stories are generated by means of a critical translation of all existing project information (e.g scope, project objectives, business requirements, content analysis, comparative analysis, brand guidelines). User research is also analyzed through this method and the majority of the user stories are generated from this resource.

User stories (derived from agile development practices) are short statements that include the role of the user and the activity they wish to perform: the achievement of some goal, in the context of some constraint. They articulate the future system from the perspective of those who will use it (see examples below). Personas and scenarios provide supporting background and context.

Example of how user stories are created from existing data:

Requirement: Display all new news content on the homepage

gets translated into:

“regular readers are able to easily see all new news content”

Or a feature description like: Podcasting

might get translated into:

“As a member I can subscribe to news stories about gardening”

It is common in the early stages of design for clients to communicate a solution as a way of communicating an intention. E.g. “users can see their shopping cart from every page on the site”. What we want at the start of the design process, however, is not a proposed solution but rather a clear understanding of what the project, and the users, are trying to achieve. User stories place the focus on what the user is trying to do, not how the system delivers it. User stories frame the problem space without identifying the solution.

During the strategy phase the user stories remain high level. They can be broken out and refined in more detail for estimating and implementation in later project phases.  At this stage of the project we also capture business goals as user stories, naming the institution as a stakeholder e.g. “As [client] I can promote the institution”. This ensures (and reassures the client) that all the objectives and emphasis in the original project assets are captured, though these kinds of user stories are likely to be replaced out over time by related stories that take a users perspective. There are some things that are not converted into user stories, for instance standards, business rules and specific technology specifications (e.g database descriptions, browser specifications etc). These are resources to return to later, as it becomes necessary to interrogate those particular aspects in detail.

Theming Stories

Once all user stories are generated, grouping and theming the stories provides a top level picture of what the site contains and reveals an initial ‘loose’ structure. It enables team members to confirm that all bases are covered and indicates the major types of patterns and flows the site is likely to support (e.g searching, looking up contact details, applying for scholarships).

In the next step, user stories are edited from a list of all the things we could have, to the things we should have. Determining what the project should do is central to developing an effective strategy. The user stories become the framework for supporting these strategic discussions about project purpose, goals and approach.

Prioritizing User Stories
The aim of the prioritization process is to enable the client team to come to an agreement on the overall goals that (in principle) must be met by the site and why. Many factors motivate clients when prioritizing the scope of a project; cost and time are common motivators, but personal preferences can also play a part. The focus on user experience provided by user stories helps people to think through the priorities in a different way. This is in part because they offer a common language that all team members can access. Talking “through” user stories also allows the client team to better understand the implications and differences between various decisions and approaches.

The value each user story has to the project depends on its relationship to the primary user groups (represented in our case by personas) and to the overall project goals. User stories are evaluated individually and in relation to each other, through open discussion with the client team. The following sort of questions occur during this discussion:

• What kinds of things would we have to do to get this done?
• Is it really important that these stakeholders (users) are able to do this?
• Is it actually possible for us to support this activity currently?
• Is it important enough to us that we should consider infrastructure/policy changes?
• Can we meet these goals another way?
• Do we need to meet these goals now?
• Is this a short or long term project goal?

Essentially, this is a discussion where the client team thinks through how the project would “look” with or without certain user stories. The aim is not to decide how the user stories should be met but rather to allow a more holistic view of the project goals and constraints to emerge. As the implications of meeting different user stories are considered, team members can get a sense of how their choices about priorities impact on the overall shape and form of the project. Based on these discussions clients are prompted to rank user stories, using the MoSCoW_Method of method of Must Have, Should Have, Could Have, Wont Have . This means all issues are captured for future reference, but the most important issues are clearly stated and agreed to by all.

Our role in this process is to facilitate the discussion and guide decision making so that agreed project goals, primary stakeholders and prioritized user stories align and support each other. Sometimes a user story will appear important, yet it won’t align with the stated objectives. In this case it is our role to ask questions like: “This user story doesn’t support you to meet your currently stated objectives, so does the user story need to be re-prioritized, or do the objectives need to change?

Why User Stories?

Flexibility, accessibility and manageability
Compared to other project documents, user stories are conceptually very accessible, they are also fast to generate. Clients can easily edit existing user stories and add their own, regardless of their technical capability. Depending on the project, users can also be directly involved in the generation of user stories. From a project management perspective, they reduce potentially hundreds of pages of documentation to just 4 or 5, making them suitable for circulation and as a shared resource for discussion and feedback.

Cohesive and exhaustive
The translation of core project information into user stories is a relatively easy way to get an early handle on the project. Reading through the user stories gives a much clearer sense of “what the project is” than lists of features or content and functional requirements. Clients can easily read through the list and ensure that their concerns have been captured. In the early stages of a project we can often be anxious of missing things, and this methods allows all possibilities to be easily collated into one place.

Common language
User stories become a common language for the client team as well as the design team. They remove the emphasis on solutions and features, and instead frame the discussion around what the project is trying to achieve. This helps clients to focus conversation around the future design possibilities, rather than be held back by existing constraints or agendas. This is particularly important when there is a conflict between different client stakeholders as it allows team members to refocus the conversation on the end goals and work backwards from there.

Shift perspective on the project (for everyone)
Lastly, and most importantly, user stories fundamentally shift the perspective of the project from a list of abstract (and potentially arbitrary) requirements to a description of user focused activities; these are necessarily more concrete and tangible and allow the stakeholder team to conceive of the project in different ways.

The UX perspective provided through user stories becomes a framework through which we can examine and explore the future project strategically and holistically. The process of prioritizing the user stories with the client team becomes a strategic intervention, facilitating discussion around project goals and purpose. The project goals and possible ways of achieving them simultaneously emerge as a result of thinking through the project from a user perspective.

Next…

In this article, we have outlined the initial step in collaboratively developing a project User Experience Strategy via the generation and prioritization of user stories. However, any single user story could be implemented in a number of different ways during the design and build phases. Different approaches will require different levels of investment, and be more or less appropriate given the constraints. Prior to moving into design a better sense of the actual scale of the project is needed. To to this we use visual, tangible and collaborative design tools such as paper prototypes, which allow team members to think through core user pathways and key interaction elements in more concrete ways. While user stories help us to get a shape of the project (what), its purpose (why), these tangible design tools support a shared conversation about potential implementation strategies (how). These steps will be presented in a future article.

Acknowledgments
The reflection on methods outlined in this article was largely made possible through project work completed on behalf of Digital Eskimo, a social design agency in Sydney whose Considered Design methodology makes embracing these methods and approaches possible. We would also like to thank our clients UNSW, Melbourne Journal of International Law and Inspire Digital and our project partners Zumio and Redrollers for their generous commitment to sharing the design experience and process, and to all the participants who give time to our projects.

UX Australia

Michelle and Penny will be giving a presentation called “Emerging a user experience strategy: People, pencils and post-its,” at UX Australia 2009. Their presentation will outline a collaborative approach to developing a User Experience Strategy: a shared vision for the project that aligns all perspectives (e.g business, technical, marketing, brand), but is driven by the potential user experience.

Here in Drupal7 User Experience Project land we’ve been moving from ‘iteration zero’ to the actual production iterations. In iteration zero we’ve been doing a lot of our strategic thinking and documenting, but now it is time to start producing output that the developers who are working with us on this project can turn into something that will be contributed to the Drupal7 Project.

There is a real cadence to the project, and although there is no time in the schedule for us to take a breather, between you and I, it has been impossible for us not to do so (just a little), before heading back into the fray. I’ve noticed this effect a few times in agile projects and I think that I’m going to try to encourage project managers to allow for a little breather at this point in future projects I work on.

I thought I’d take a moment to share with you some of the other shifts that start to happen as we move from Iteration Zero into the Production Iterations.

Communication Framework: From Abstract to Concrete

As I’ve mentioned in the past, a big part of the time we spend on this project is spent either communicating with the community about the work we’re doing, our process and our ideas, or trying to work out a better way to communicate with the community.

One of the biggest challenges of the Iteration Zero stage in the project is that it is, by and large, a series of quite abstract and strategic discussions.

It is really easy to forget that many people find abstract and strategic discussions really difficult. I think there are particular types of brains that embrace the abstract better than others, but experience in this project phase is also very helpful.

In Iteration Zero there is often a lot of writing and talking and not much making/showing – this can create a very challenging environment for project participants. It is pretty easy for people to have vastly different interpretations of the same concept and it can be difficult to make sure that everyone is on the same page with the higher level strategy for the design and product. I’ve experienced this recently not only with the Drupal project, but with a few other projects I’m involved in.

Abstract discussions can be difficult to grok due to their predominantly conceptual nature.

It is pretty easy for people to have vastly different interpretations of the same concept and it can be difficult to make sure that everyone is on the same page with the higher level strategy for the design and product.

I can’t begin to tell you how many times I have explained and re-explained the very same concept, each time thinking that it’s been communicated clearly, only to discover that we still have at least two very different ideas about how something is going to work. There are at least two reasons for this: firstly I have to take responsibility for communicating – if the message isn’t being received I have to re-evaluate either what or how I’m communicating. We also have a second and somewhat unique problem when communicating with the Drupal community and that is that they have a tremendously strong mental model of How Things Work In Drupal. Every time an idea is presented the community almost invariably tries to map it directly to their mental model of How Things Work In Drupal – this is natural and what we *do* with mental models, but when the concept we’re suggesting actually breaks the model, we can run into trouble. It just doesn’t compute! It becomes abstract, difficult to understand, as we have to try to find ways to make concepts more concrete.

Iteration Zero can be a stressful time as a result of this abstraction – people aren’t really certain that they know what you’re talking about, but you’re also asking them to make decisions that will be really significant in shaping the product they’ll be getting at the end of the project.

I think it’s pretty common for people to be fairly fraught towards the end of Iteration Zero.

Thank goodness it is also around this time that something excellent happens – things start to become a little more concrete. There are still a bunch of abstract concepts that need to be agreed on, but as designers we’re also starting to get our heads around exactly how things will fit together and we can start to communicate that.

This is around about the time that we had a fundamental overhaul of the way we’ve been communicating with the Drupal community and interested onlookers on this project.

Towards the end of Iteration Zero we were starting to get a little down about the some of the feedback we were getting on the D7UX project – people were saying that they didn’t want to get involved because it was too intimidating for people who didn’t have UX experience and expertise, that they didn’t think it would actually happen or be a success, that they felt that the discussion was too disjointed and widespread.

It was clear to us that we needed to change the way we were engaging with the community to help them help us. Essentially, we needed to change the structure of the conversation from it’s abstract Iteration Zero format to a more concrete format appropriate to the production iterations, and, we suspected, to a format that most of our participants would find much more comfortable.

Over the course of a day, we created a ‘Project Framework’ on the D7UX site by breaking down the project into it’s main component parts and providing a wireframe, description and outline of ‘what we’re thinking’ for each part. Threaded comments allow people to give their thoughts on each component as it evolves over time.

Allowing people to participate in a place that is most comfortable to them is a key part of our communications strategy. We wanted to continue with this strategy even as we move into this new phase of the project, but also to aggregate the discussions into one place and to facilitate this we created a system of tags for the project components and put together a series of Yahoo Pipes to pull tagged content together. We added a link to these pipes on each of the component pages in the framework.

It was a pretty big overhaul and quite a time consuming process, but almost immediately we noticed a significant difference in the way that people were communicating with us on the project – the interactions became much more focussed and productive and felt a whole lot more positive, and that trend seems to have continued. It also makes it much easier for us to be more conversational with the community in the project – thanks to the simple addition of threaded comments and also the aggregation of the main part of the conversation into one place.

Overall, we’re really pleased with the effect that changing the format of the conversation from abstract to concrete has had on the project to date and the effort involved has already been rewarded.

The Challenge of System Design with User Stories

Another major challenge that we’re butting up against at the moment is to try to make a system design fit into an agile environment.

I’m a big fan of agile methodologies and have had a long term interest in finding better ways for UX practitioners to engage in agile methods. Unfortunately, there is no denying that pushing a design project like this one into agile iterations is tricky.

The way that our user stories are being developed at the moment is that the project manager from the developer agency (Acquia) is writing user stories then pushing them over to us to check that they are right and for us to adjust and re-order as required. To date, we have mostly let them sit in a large spreadsheet whilst we focus on the design strategy (iteration zero) and try to ignore the need for user stories.

We’ve done quite a bit of work on developing an Audience Matrix that allows us to take quite sophisticated ‘views’ of the design from multiple audience perspectives, but to translate this into user stories is untenably complex. The alternative to date has been overly simplistic. We are struggling to find a way to make good use of our audience modeling work to date without breaking agile.

Another issue that we’re butting up against is the nature of system design and templating in an agile environment. There are sets of design elements or template components that would ideally be designed in components then re-used throughout the project – for this project examples of these would be the admin header, the overlay window and the edit-in-place interaction model. Describing these using user stories is incredibly clumsy and inappropriate.

Once these elements are built and we start looking at user pathways that make use of them for particular tasks and outcomes then user stories will come into their own, but it seems that in the same way that developers need a piece of time to set up their development environments and databases without requiring user stories being used, designers need some time to get the ‘design environment’ set up without requiring user stories.

Again, this is something that I’ve come across on a number of agile project I’ve worked on but I’ve not seen any allowance for this way of working in Agile UX project methodologies.

If you’ve had similar challenges and some ideas or solutions then I’ve love to hear from you!

Update on Crowdsourcing Usability Testing

In my last update I was telling you about the Crowdsourcing Usability effort we had launched. Since then we’ve seen that WordPress have launched a similar campaign and they managed to get coverage in the New York Times no less, so we will be watching their progress with interest. Exciting times!

Launching Microprojects

Want to dip your toe in Open Source Design? Help out with D7UX? Well, here’s a great way to give it a try – sign up to help out with one of our microprojects! You need to commit just 12 hours over 3 weeks, but you’ll get a feel for what it’s like to design with one of the most vibrant and clever communities you could ever come across. Be warned, it’s challenging but potentially very addictive!