oneux | designing experiences

agile and user experience: initial thoughts

I've been searching around and came across a number of articles talking about the uncomfortable relationship between agile and user experience. The consensus appears to be that though challenging, user experience can be incorporated into agile practices and help produce not just working software but also usable ones. Of course it is possible, user experience professionals will make sure the user is heard regardless of what development methodology is used. To me the issue is not whether UE can be incorporated into agile, but how can UE transform agile approaches so improved user experience is part and parcel of agile approaches.

Note that innovation does not feature when talking about agile but references to 'the simplest thing that could possibly work' are common. Well, this is probably fair because you cannot possibly innovate without real insights into user needs and behaviours. Anyway,

• Regardless of how UE can be bolted on to agile we need to remember that agile is a software development methodology and all its practices, tools, artifacts are designed around helping developers build working software: Producing working code is at the core of agile, user expedience is not.
• Agile approaches are supposed to make the developers' life easier, the processes used are designed to help developers successfully build and test (note not necessarily user testing) small pieces of software in small periods of time thus minimising risk. In that sense, agile approaches are inward looking.
• Focusing on customers is not the same as focusing on user. 'Customer' in agile is quite a vague term that incorporates the client, owner of the product to be built, as well as the final user base. As a UE practitioner I would argue that identifying and prioritising the end users is critical to building successful interactive products.
• Agile passes the usability bucket over to what is called the 'product owner', which in most cases would be the client, internal or not, commissioning the work. Agile, here, makes a  dangerous assumption, namely that  companies have a clear and deep understanding of their customers' needs and motivations. Furthermore, assuming that there is someone at the client organisation that 'owns' the customer  - which would normally mean they own and manage customer segmentation based on market research, not user research, - it is not likely that they will be the 'product owner' .
• To end my thoughts on a positive note,... User Stories, well there is something that can make agile uer cnetred... let's see...

More thoughts soon...

agile and user experience: the questions

Agile, being a methodology that uses iterative techniques and relies on people should work great with UE. But do agile approaches and UE work well together?

• Where and how does user experience fit in an project following an agile methodology?
• Why is there not a dedicated stage for user research?
• Is sprint 0 when you do collect user requirements? How do the spikes fit in?
• How do you ensure usability in a methodology that is not using prototypes?
• What are the benefits of working in small cross functional teams?
• How effective are sprints for ensuring user needs have been taken into account in the design and built?
• What is the UE involvement in Scrum?
• How do user stories differ from personas and user journeys/ scenarios?
• Are user stories based on requirements?
• How effective are user stories?
• Do developers have the skills and insights to create user stories?
• Why is the product owner the voice of the customer?
• Are UE professionals part of an agile team?
• If part of the team, what is there role?
• How can a UE improve the quality of a sprint output?
• Where does usability testing fit in? at the end of each sprint? just before release?
• It appears that agile methodologies are inward looking while UE is outward looking
• Do agile methods foster innovation?

Over the coming months I will be thinking about these and more issues and writing my thoughts on agile and user experience. All your contributions are welcome.

              

       

when getting out is the only way forward

When User Experience is used as a euphemism for Interaction Design and Information Architecture; when exposure to users is an afterthought and also contested internally; when user centred design takes a back seat to visual design; when user research is taken out of the hands of the UE team, then there are only two ways forward:

A) attempt a cultural shift, reposition UE at the centre of the design process, or
B) leave them to it and find an environment where you can make a difference.

Repositioning UE at the centre of the design process would be my preferred option. However, it requires a
strategic decision, as well as a sponsor from the managing team since such a shift would inevitably make some stakeholders uncomfortable to say the least. In the absence of such a strategic desire  the only way to still attempt repositioning UE would be to go it alone and crash head on with internal forces that see UE as an add on, a tick the box approach. Again, this can be an option if there is a clear mandate and some board level backing. However, if there is no such commitment then an early exit is the only viable solution.

It is more important to add value where UE is considered integral to the design process than fighting a battle without the required support and strategic foresight.

            

       

owning the user experience

So, here is another question: Who owns the user experience in a digital agency, the UE or the Research & Insight (R&I) teams? It transpires that R&I are closer to the user and are better positioned to champion user involvement in the design process. My brief exposure and experience of digital agencies suggests that UE teams have been relegated to Interaction Design and IA; not to say that either is not important, but it appears that they have lost touch with the end users of their designs.

The problem with R&I owning the user experience is that the people within R&I teams tend to have a market research background and carry with them different sensitivities to user needs and requirements. While some of the tools and methods used in traditional market research are familiar to UE professionals, market researchers are more interested in numbers, trends, and market segmentations than getting under the users' skin and creating an environment that fosters innovation. For example, they may propose focus groups as a means of collecting user requirements while it has been proven that focus groups are notorious for understanding user needs. However, focus groups can reveal a trend, however unreliable, that the creative team will pick up and develop a final design and product.

I would argue it is time for UE teams to reclaim ownership of the user experience and work closely with R&I to A) ensure that the right methods and tools are used, and B) evangelise user involvement within agencies by presenting successful case studies.

I know there have been arguments that the user experience should be owned by the entire company and not only by a UE team. While I fully agree with this position, the user centred approach to design needs to be managed and promoted by a defined entity and not be left to the entire organisation.

service design conference

Emergence 2007 will take place between the 7th and 9th of September in Pittsburgh. Hope to see you there. Here are some more user experience design conferences.

e-government

            

 

The following letter appeared in The Guardian in Nov. 06.

Having worked on user experience projects for online government transactions I am not surprised with Michael Cross’s conclusion that the e-national project has added a ‘digital interface to that mess’ (The tangled web of government, November 2).
Ambitious targets for e-enabling transactions make great headlines but do not guarantee that the public would jump on the e-wagon and never look back. The key to successful e-government services is to ensure that the way the transactions are e-realised is aligned with users’ needs and requirements. Simply providing an electronic version of a badly designed form does not make the process simpler or more bearable.
An IT-centred process is not the solution to what clearly demands a user-centred approach. Throwing the latest IT solutions at the problem and making sure all the ‘relevant offices [are] connected electronically’ is certainly a challenge but one that still misses the point: it is the users’ experience that all e-government solutions need to support and improve. This is the only way we can ensure that IT does not operate for the benefit of the institution but that of the citizen.