Good design is hard to do. The very nature of human centred design is confronting, challenging and often uncomfortable. Every project builds up a collection of challenges along the way, which can pose significant risk to the project’s success, and if we don’t tackle them head on they can be detrimental for everyone involved. How can  we share and learn from each other’s challenges?

At Neoteny, we refer to the collection of challenges in a project as its ‘challenge pile’, given they’re exactly that; a pile of issues, constraints and problems. We keep track of the challenge piles using walls in our studio for each project. Some are collections of post it notes, others are photographs, drawings, diagrams, scribbles or hand written notes. Each week as part of our work in-progress meeting (team jam), we take stock of each project’s challenge pile.

We ask ourselves the following for every challenge:

• How did this challenge come about?
• Briefly establish the current reality, including:
  • What has it cost the project? Not necessarily in financial terms, what has been the cost to our momentum, resources, client expectations etc.
  • What is the potential impact? In what areas?
  • Could it have been avoided? How or why not?
• How have we handed it thus far? As a group, explore options for how we handle it moving forward.
• Agree on proposed solutions or new approaches and secure buy-in from everyone involved.
• We’ve found that this structure helps us stay out of the drama whilst understanding the drivers for each challenge, and then focus on solutions. This makes the process much more collaborative and productive, we aren’t sitting at our desks sweating over something we could probably work through together in a few minutes.

We recently had a team jam, and here’s what came out of our challenge pile review:

1. Customer needs and business requirements collide.

This project is in its early stages. The client came to us with a new product that they wanted to develop, the first step was to research the product feasibility and desirability in the market.After conducting research aimed at validating the customer need for a new product, we found that what the customer needed and what the client planned to launch, were two very different things.

We’re currently in discussions with the client to try to shift the project objectives and focus, to meet real customer needs. As a group we decided not to proceed to stage two unless we could get their buy in on a revised approach.

Question for readers: What would you do in this situation?

2. Budget streams are unclear for future phases of work.

We’ve been involved in projects in the past that have unclear funding streams for future work. This is especially common in large corporates, where steering committees assign funds based on a comprehensive business case analyses including return on investment predictions. These can’t necessarily be defined without first doing some work. The problem with this structure is that you have a team of stakeholders that can only see as far as the next steering committee meeting. This makes a design project with a strategic foundation i.e.  something that’s designed with the whole in mind, very difficult to manage.

This particular case was flagged early because we’ve seen the warning signs before. The signs included hearing things like:

• “If we build this…”, highlights the fact that the stakeholder doesn’t believe this project will make it to implementation.
• “We need to show results by June…”, if you ask why, you’ll probably hear something like “that’s our next steering committee check point”.
• “We won’t be able to build that”, if you ask why, you’ll probably hear something like “because the next budget release won’t be anywhere near that much”.

In the past, this issue has created a divide between the client or project stakeholder group and the design team. Whilst the stakeholder group is focused on securing the next round of funding to ensure that this phase can move to implementation, the design team is focused on exploring and exposing every possible opportunity for solving the design problem.

We’re currently working with senior management to ensure we have their buy-in throughout this project. In our experience, we’ve found that if the person signing the cheques is on board with the approach, the whole stakeholder group is much more relaxed and inclined to get their hands dirty in design.

Q: Have you experienced this before, and if so, how did you get around it?

3. Stakeholder groups have varying ideas of the project objectives

Have you ever been in a project meeting and realised that the client team doesn’t agree on the project’s objectives? This is an awful moment for a designer. It’s the moment when you move from designer to mediator. Playing mediator with your clients is generally not a lot of fun and not how you want to be spending your energy.

The design team typically work with clients to reach a shared set of project objectives. If you find yourself in a situation where you think this has happened but it isn’t the case, then it needs to be dealt with immediately. This agreement needs to be made before design work can start. Of course, these objectives may shift and be adjusted as part of the design process, but the aim is for adjustments to be made as a whole, not as a fragmented set of perspectives from different stakeholders.

We’re currently experiencing this on a scoping project we’re working on. It came about in a workshop, where up until that point, the team seemed aligned. We handled it by stressing the need for a shared project vision and refusing to move forward without one. We managed to facilitate developing a shared set of objectives, prioritising them and we’re currently working with the client to ensure that every stakeholder is in agreement on the vision for the project.

Without this shared vision, we put the success of the project at risk because no one is clear on what success will look like. We’re currently working through ways to communicate this in a more explicit way to our clients before we start on their projects.

Q: Perhaps it’s about signing off on the project vision, would that make people more accountable?

4. Mystery stakeholder stomps on the project.

Does this scene sound familiar? The design team is working away, the client is happy and excited, they’re getting involved and spending time designing with us. Then BAM! Along comes the mystery stakeholder who has significant influence, but just “doesn’t like blue”. In most cases, the mystery stakeholder is a fairly senior member of the client team who hasn’t been along for the ride and is looking at the design solution without any understanding of the brief, the agreed approach, the challenges or the project’s constraints. This situation can be crippling. Challenges like this can impact resources, motivation, relationships, momentum, time and budget. You could argue that it’s the design team’s fault for not ensuring that all stakeholders were engaged, the project owner’s fault for not engaging the full spectrum of players, or the mystery stakeholder’s fault for stepping in with the ‘I’m gonna leave my mark on this project regardless of how you got here’ kind of attitude.

We’ve started to enforce what we call a stakeholder roll call. At the start of every project, and within our terms and conditions we gather a list of stakeholders, their roles and responsibilities and have the project owner sign off on this list. The full list of stakeholders are required to sign off on all milestones and agreed deliverables.

We acknowledge that the stakeholders may change, but the terms allow for this situation and protect the progress we would have made in the project up to that point. The success of this approach remains to be seen, though what it does achieve is a level of accountability agreed up front for the potential impact of those ‘stomping moments’.

Q: How do you protect your projects from random stakeholder stomping? How have you dealt with this situation in the past?

Where To From Here?

As you’d expect, there’s a ‘magical box’ of learnings and insights created by each challenge pile. It’s what we choose to do with the magic that makes the obstacles and the heartache worthwhile. I’m sure we’ll learn a hell of a lot more as our company matures, but here are some of the more salient ones we’d like to share with you:

• There’s not always something ‘to do’, there’s something ‘to know’. There are situations we can’t ‘solve’ in the context of the project we’re working on. But being aware of the specific challenges and carefully managing expectations accordingly can be a very effective approach, one which better supports our potential success.
• As a company (and perhaps as an industry) let’s be more reflective. That doesn’t mean we have to wade into the drama or analyse it ad nauseam, but we do need to nip things in the bud, be honest with ourselves and the team, be open about the potential impact that the shifts might have, and involve everyone.
• Getting the players involved as the challenges arise. Rather than keeping our ‘dark passengers’ under our hat, and suffering in relative silence, all with a smile on our face, let’s face the challenges together! Clients and project stakeholders are often quite pleased when you invite them to be part of the solution. Any shifts to the project approach are also much more likely to fly if we’ve got buy-in from everyone involved.
• Sharing the good the bad and the ugly with our peers. Let’s foster a culture where we share both our triumphs and our failures, rather than keeping the latter closely guarded. As a collective mind, I’m sure we can come up with some inspired, insightful ways to circumvent and also completely avoid some of these challenges.

We believe that we can get better at this thing called ‘design’ if, as an industry, we can make the most of lessons we learn from these challenges. After all, they enable us to be more resourceful, they give us an opportunity to be more creative, to build stronger teams and deeper relationships.

So, what do you think?

Michelle is one of the speakers at UX Australia 2010, taking place 25-27 August 2010 in Melbourne, Australia. The conference has sold out, but workshops are still available, or you can go on the waiting list. See the UX Australia site for details.

In our previous article, we focused on the first step to developing a User Experience (UX) strategy by presenting how user stories are generated, themed and prioritised, as a means of helping us to understand the shape of the project (what) and its purpose (why).  In this article we focus on the use of scenarios and paper prototypes to support a rapid and collaborative exploration of potential implementation approaches (how).

An Approach to UX Strategy

The goal of the strategy phase is to ensure that all stakeholders are similarly focused and aligned around project goals, i.e there is agreement in principle about the purpose of the project and the priorities for implementation.  A high level agreement to what the project is, why we are doing it, and how it will be achieved reduces the risk of budget blow outs or conflicts in the design phase by ensuring that all project stakeholders have similar expectations. In addition, it is only through an understanding of the scale and complexity of the project that the design team can accurately, or at least confidently produce a budget or estimate for the project.

Our approach to the development of a UX Strategy is motivated by three interrelated, pragmatic and theoretical drivers:

1. Firstly, getting the client team on board and in agreement during the strategy phase relies on these stakeholders having a shared understanding and vocabulary. Tools like scenarios and prototypes help to externalise issues and make them available for shared conversation.
2. Secondly, they also allow the project team to collaboratively and rapidly investigate options and expose constraints. The tangible and visual nature of these tools allows us and the client team to think, explore and discuss the potential project in a more concrete way by grounding conversations about the project in its context of use. This ensures decisions about approaches and priorities contained in the strategy are appropriate to the opportunities, boundaries and constraints of the particular project.
3. Finally, the third and perhaps most important reason is that tools like user stories, scenarios and paper prototypes frame the discussion about the project strategy from the perspective of the user experience. Doing this collaboratively is an opportunity to expose, explore and align the various agendas and perspectives of stakeholders and work through how they might come together in design. As a result clients are better able to understand the implications of project objectives and priorities, and refine them based on the impact this will have on the potential user experience.

From User Stories to Scenarios

Any of the high level user user stories generated as part of the early strategy phase could be implemented in any number of different ways. Different approaches to implementation will require different levels of investment and be more or less appropriate given the project context and constraints. So, once a list of user stories has been developed (as described in the first article) the next step is to identify the key scenarios. The intention is that by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why. In our experience fleshing out 4-6 scenarios will allow us to explore enough of the key aspects of the site/application. If not, then this is a sign that the project may need to be divided into smaller phases.

The intention of doing this work is not to find the solution or define the architecture per se, but rather to explore possible approaches and agree on an appropriate UX Strategy. We also hope to expose risks or contradictions between expectations and constraints (e.g budget).

… by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why… to explore possible approaches and agree on an appropriate UX Strategy.

Selecting Key User Stories

The user stories fall, more or less, into two categories. The first are that those that are simple, familiar or unambiguous enough that we can feel confident about budgeting them and resolving them as part of the design phase. These might include user stories that use common UI patterns that we are familiar with or that we have resolved many times before. The second group are more like ”black holes”. By that we mean ambiguous, complex or particularly unique to the project; if not better understood they will pose a risk to meeting deadlines or timelines in the design phase. Our goal is that by the end of the strategy phase we can a) be sure that they can be implemented and b) put a cost against them.

The process of fleshing out this latter group in more detail allows the scope and nature of the project to emerge through a focus on user experience. At the same time it exposes and challenges some of the assumptions and expectations held by stakeholders, or embedded in existing documentation.

The following is an example of a key scenario from the redesign of a university website:

As a potential student I can find out about the application process, find an available supervisor and apply.

This scenario is derived from these user stories:

• As a potential student I can find out about the application process
• As a potential student I can find an available supervisor
• As a potential student I can apply to study

The example scenario above was chosen because it represents a complex pathway that would be completed by a potential student over several weeks or months. Walking through such a scenario forces us to explore and confront a number of strategic, political, technical and user experiences issues.

Mapping out scenarios as user pathways

Once the key scenarios have been identified and agreed upon with the client, they are mapped out as user pathways.

Initial pathways are generated using a walkthrough process represented by post-its. We take each scenario and ask ourselves what would we would need to provide in order for that scenario to be achieved. We have to hand personas, business objectives, content examples, accessibility guidelines, and any relevant technical specifications to assist our decision making about how people might proceed and what they might need to do so.

Each step gets a post it/sketch to represent it, as shown in the image below. We aren’t working at the level of pages yet, just creating a trail of things that would need to exist in order for it to be possible to fulfill that particular scenario. This process allows us to think about the experience as a dynamic thing that happens over time.

Mapping Pathways

Analysing pathways

All the scenarios are mapped out in the same physical space and in relation to each other. If there is some cross over between the scenarios then that is shown physically by an intersection in the pathways.  It is likely that the pathways of earlier scenarios may have to be adjusted in response to what emerges out of the later scenarios. It is an iterative process and depending on the scale of the site, might take a few days to complete. In the image below, intersections in pathways were exposed via clusters of different coloured post-it notes.

Identifying Pathways

Rather than exploring or defining the approach to design or user experience from the perspective of features, this process allows the shape of the site to emerge through an exploration of user activities. Particular patterns about potential use can then be identified, which feed back into the strategy development process. For example, we are able to see that particular areas of the site, or pieces of content contain information relevant to most stakeholders, while others have value for only a small number. These patterns can inform decision making about priorities for the site and help clients to come to agreement in principle on approaches to various aspects of the project, including where time and money is best spent in the short term.

Drilling down through prototypes

Visualising the user pathways also reveals underlying technical and content needs and raises questions around feasibility, content and functionality. In some cases the issues and questions raised are better understood at a more granular level, i.e how they impact on specific interactions via the interface. Paper prototypes or mock ups are then used to rapidly drill down into these “high risk” areas. The image below displays an example of a paper mock-up used to explore possible ways of supporting a searchable index of university scholarships.

Sketch Prototypes

Seeing the potential user experience mapped out in this way provides the client with a different perspective on the project and this allows them to discuss the project the different ways. For example, this process will  expose how a scenario or user story, currently prioritised by the client team translates in design into a potentially very complex requirement, or requires the availability of a certain set of content not currently available. It can expose tension or conflict between a priority objective and what it would actual take to make that happen.

Often at this point, project realities begin to sink in and project teams are forced to realistically assess what could be achieved in the allocated time frame and budget. The visual pathways, mock ups and paper prototypes become visual and tangible aids to explain the issues and options, and support discussion, negotiation and resolution about appropriate approaches and priorities. We have found this technique is very effective for generating and supporting constructive discussions with the client when decisions about priorities are needed. The client has the opportunity to understand the impact of various decisions and requirements about technology or content in relation to the user experience. This supports the development of design principles and guidelines, and helps clients come to an agreement on approaches to particular aspects of the site or application. It can also lead to a revision or shift of emphasis for the project objectives.

The process of thinking through actual prototypes provides these stakeholders with a new way of seeing and new language for describing what is most important. As a result the client team is better placed to decide and describe the most valuable outcomes and confidently direct resources towards the most important elements of the project.

Summary

Creating an effective User Experience Strategy requires the alignment of perspectives such as technical, business, content and brand with that of the user experience. In this article we have described how we support clients to develop a User Experience Strategy that takes into account all these perspectives, based on an understanding of how it will translate into design.

We believe that a core part of developing a design or User Experience Strategy is about interpreting how ‘abstract’ business goals are translated into a specific design project. Scenarios and prototypes are light weight, visual tools that can be used to assist clients to rapidly envision the potential experience for users. They bring a tangible quality to conversations that can otherwise be ambiguous, allowing team members to collaboratively think through project goals and approaches to implementation. They force us to deal with the concrete issues of use in situ, provoking and facilitating critical conversations about overall strategy, opportunities and constraints prior to moving into the design phase. Most importantly they frame questions and decisions about functionality, brand, content and technology in relation to the impact this will have on the potential user experience.

As designers, we deal with users perspectives and the concrete situated issues of use as part of our daily practice. These collaborative tools enable the user perspective to sit at the centre of the discussion and decision making for our clients as well.

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.

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.