There is an assumption that the standard set of UX activities and outputs should simply slot into agile development practices unchanged.
Lets flip the question and ask what would a UX Design project look like if you were to manage it following Agile principals.
The point of reframing the question is to directly challenge the UX community to rethink its approach and bear the burden of transformation in order to move towards supporting a more effective and enjoyable way of actually delivering real, live user experiences for customers.

Looking into Lean, and i cant believe how closely its principals align with UX principals

from http://www.lean.org/WhatsLean/Principles.cfm

5 principles of Lean thinking

• Specify Value from the perspective of the final customer
• Identify the Value Stream and eliminate every step, action, or practice that does not add value
• Make the remaining steps occur in a tight, integrated sequence so that value Flows smoothly to the customer
• Let Customers Pull products rather than push products to them
• Pursue Perfection through continuous improvement

if that’s not UX i dont know what is – not sure if value stream mapping makes you more money than UX. I might even change professions !

the following diagrams are taken from an excellent document from the Journal of usability studies called “Adapting Usability Investigations for
Agile User-centered Design” by Desirée Sy from Autodesk.

The first diagram simply captures a method for running parallel tracks of design and dev on an agile project. A great one for explaining how design and iterative development can work together… and more considered than the “ill just stay ahead of you guys” method

The second diagram structures a User Experience Card wall that helps keep design elements and where in the prototype / testing / ready cycle they are. Great !

Its really worth having a look a the entire document at http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html

User Experience flows, its not static.

If your designing experience, you need to model movement.  It’s the path and flow in user experience that matters, it’s the sequencing and simplicity of the journey that counts.

With this in mind, old definitions of “wireframe fidelity” simply don’t make sense any more. It’s not about pages, page structure or layout in the same sense that buildings aren’t about bricks, windows and doors.

Bricks and mortar may be elements may make up the experience of buildings, but they simply define the boundaries around which movement may occur. Architects define the boundaries of space, and the experience of living within the build environment is an experience of what movement and functions can occur within these boundaries.  Architects simply define boundaries and connections. Experience Designers need to understand that websites and applications are the same.

This realization requires a very different approach than wireframing. Rather than simply documenting where a link goes, the goal is to model and start experiencing what moving around a site feels like as quickly as possible.

It’s the space that your design affords, and the feel of moving thru this space that you need to get a grip on early. Prototyping experience is about understanding this space.

————————————

The day after i wrote this post i stumbled across this… its a great way of capturing the multidimensional nature of fidelity

http://www.boxesandarrows.com/view/integrating

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context

The longer I do this job, the more I think that there are certain qualities, or attitudes that can make a real difference to ones ability to get better designs implemented, and generally enjoy the job more. Here’s my hopefully controversial list of qualities that will help you really rock.

Be Respectful

Focus on trying to understand and empathize with the people you work with…they are smart people and do difficult jobs. Respect will come easy after that.

With respect and understanding comes trust… and if you really want to design something great the first thing you need is the trust of the people you work with and respect from them.

Be Collaborative

Moving from design dictator to design facilitator is a shift towards true collaboration. Design within a multidisciplinary team (is there any other type of team?) requires a shared vision and if you really want things to happen then sharing decision making and taking people on a journey towards an agreed solution is a great place to start.

Learn to move from “dictating” the UX design to “facilitating” the UX design… and watch how people really pick up your design and run with it.

Be Trusting

I think its essential to trust that people are doing their best, and that if they say “that’s to hard”, or “we should rethink this” then trusting that its coming from a good place will, if nothing else, help you approach the conversation about why its hard in the right way.

Investing trust in the business is also essential, questioning every business decision they make is not exactly going to help – so trust that these guys are actually thinking about their jobs and that their priority decision are considered. This doesn’t mean you can attempt to better understand where they are coming from , but again, if nothing else trust will help you approach the conversation in the right way.

Dive deep into the data

This may seem like a strange one to add, but as a UX designer I think one of the most important things is to understand the underlying foundation of what “can” make up your design. In the end I think applications are very simple, all you need to understand is that there is data at one end (e.g. the XML returned in some API) and there is your application interface at the other end. Its rare that you can make fundamental changes to the underlying data, but you have almost complete freedom (in a new application) in deciding what to do with that data. The page flows, the presentation and passing of that data is in your hands.

Diving deep into the data will also help you understand what your devs are doing, it’s a shared place that you can build conversations around – and it also will often give you a deeper understanding of the wider system (e.g. how the data got into the system via a sales consultant and what was driving them as they were creating this content).

Once you understand the data structure, then both dev and the business will give you more time because they know you understand the underlying issues that they are dealing with.

So don’t be scared – go and have a look at that XML and understand the basic request and response mechanisms that drive data to your application.

Take the initiative

Taking the initiative early is the best way to maneuver yourself into a position where you can have a real impact on the project. At the beginning of any project there can be a general lack of vision around how its all going to work… in fact there is often confusion about what’s even required. This void is debilitating for everyone and the only person who really has the ability to push the project forward is you (UX). Its imperative that you take the initiative in this early phase and work as hard as you can to clarify a vision and direction – this is not something you do in isolation – it’s a journey you need to take everyone on. Once you have built trust and have the decision making initiative everything becomes easy and fun.

Drop your ego

Care enough not to care. Be flexible, and accept that you may not always be right. Dropping you ego is the first thing you need to do if you want to be collaborative and inclusive in design decision making. Trust me – you will get better results.

Focus on high fidelity, and making the abstract concrete

While you may have the entire design in your head, its likely no body else does. Focus on describing the design vision in high fidelity, and on making the experience as easy to understand as possible. I always develop high fidelity blueprints which I place on the walls around the devs. I do everything I can to make understanding the UX design as simple as possible. Forget abstract site maps and complex page flows that reference other documents – simply past up every page template in the application on a wall, and show how these all link together. The aim is not to show every state possible – its to get a high level understanding of how the entire site works. You will be amazed how well people respond to this method. And if you thinking that your application is to difficult or complex to do it – well that’s bullshit. Its up to you to figure out how to communicate this – focus on expressing the typical straight line page flows if approaching it from a template point of view is to hard. If you think its to hard to design or document this then imagine how hard it is for the devs to build it. In the end Focus on producing a high fidelity definition of what’s to be built, and on making the abstract concrete. You may find yourself collaborating with the devs to make the design more consistent, efficient and simple – and in my experience this is definitely a good thing and most often these changes make for a better UX for the users.

Prototype and test

You may be a genius – but thinking hard about a design can’t really give you the feel… best way to get a good feel for the design is to build a proto early and test it. Sometime I think the real value of user testing is in simply the act of building the proto and getting the time to watch people use it over a few days. Nothing gives you a better feel for it.

As an aside a proto is also a brilliant tool for the business to communicate what you’re intending to build… and a great tool for the devs to understand what you’re thinking.

Choose your battles wisely

Remember what your trying to achieve… a great UX for a majority of the users. At various points throughout the build process there will be times when you need to either fight for something, or take the path of least resistance and accept a slightly comprised UX for the sake of simplicity and protection of the final delivery date. These decisions are not about ego, or you getting what you want. Its during these moments that you can either gain the respect of your collogues, or start heading down the dangerous path of being sidelined because you don’t seem to understand the bigger picture. Its terrible to say this, but its not always about the user…. Opps – did I just say that?… or perhaps more precisely it is all about the user and sometimes taking a pragmatic approach to crafting the overall best result for the user is best served by releasing a solid app on time, to budget and then focusing on iterating the application in future (something that is more possible when you get the trust and respects of the people who actually fund future projects)

Your ability to manage relationships and conflicting agendas during the project will directly reflect on your future chances to drive continuous improvement of the application post delivery. So choose your battles wisely and remember it’s the war your trying to win.

And don’t forget the users

Most of this advice is about how to work better in your teams. I’m assuming your already a great UI / UX designer and understand the importance of focusing on the understanding the users needs and goals, the likely tasks and scenarios of usage that support these, and all the other basic UCD type principals that inform what you should be doing.

Without a set of principles to frame design decisions its difficult to avoid a scattered approach to decision making. With this in mind Alex, Ben, Julian and I set out to define our own set of Mobile Design Principles.

i should be clear that we used Googles design principals as a starting point for the discussion, and there are elements within our list that reflect this…. So, While the outcome is not unique or revolutionary in any way, the process of developing these was very useful.

Gaining a shared understanding of what we value, and how we priorities these values can make day to day “differences” within a design team much easier to overcome.

The list of principles is shown below… Ive found the core to be very useful during design discussions and workshops. The secondary ones arnt as well considered, but its usefull to understand these are of a lower priority when making design descisions.

Core Principals

1. Useful
   Focus on users and their needs and goals
   Always question “what is the core usage scenario”,  “who is using this”, “why are they using it ?”
2. Simple
   Strive for simplicity (avoid clutter)
   Always question “why is this here”, and “is this in its simplest form”
3. Obvious
   Engage beginners
   Does this make sense at first glance for a new user
4. Easy
   Avoid unnecessary input or interaction. Avoid over-engineered UI’s
   Always ask “can this be easier”
5. Immediate
   Focus on speed and time to task
   delivering value back to the user as fast as possible
   
   

   Supporting Principals
   

6. Responsive
   Make interaction responsive
   Question “is it clear what has just happened?”
7. Attractive
   Look and feel does matter
8. Control
   empower users through personalization and customization
9. Innovate
   innovate where appropriate. Focus on today and tomorrow

oh, and a special one just for me… Spelling Matters :0

There is nothing more sad to see than a frustrated, misunderstood designer.

One common source of frustration is the “they didn’t build it like this” syndrome, which underlies the basic point I am trying to make in this post.

That is that often design is seen (by designers) as divorced from the build, a deliverable that is separate to the actual production product. A deliverable expressed in the “Design Specification” My point is that the design spec is worthless if it does not get implemented, so your job is not to design things… its to influence and support the process for developing “what gets built” (and in the process make sure what gets built is well designed) Thankfully for me this means I don’t have to spec as much as I once did – great ! But it also means you are often a design facilitator, rather than a design dictator. It means you collaborate with all the stakeholders to define a clear and considered path for delivery, a process that last the duration of the project. The old waterfall “spec and forget” days are dead.

So as the title suggests : the design IS what gets built (not your spec).if your spec is not built its your failure at engaging, communicating & understanding the job.

p.s. – for a guy who is eternally content and happy, I sure sound angry in this blog. Promise to be upbeat soon 

I’m becoming obsessed with the idea that the internet, defined broadly as the experience of “connecting” via a browser is a total failure – or at best a clumsy infant.

Its failure is best understood by trying to imagine “online” spaces and places as physical, 3 dimensional architecture. It’s a failure that’s highlighted by trying to place yourself in this virtual city, and truly trying to connect with and understand the ebbs and flows of activity with your wider community.

While we have constructed the “window” – one of the most successful metaphors in navigating online space, I can’t help but think we are all trapped within this window metaphor. Every day we sit down, and re-construct towers of isolation. A tower with one room, and thick lead walls – a tower that morphs and changes to accommodate the multiple windows that we look out of, but that never allow passers by to look in.

We have been fooled, happy prisoners distracted by our “magic like ability” to conjure up new windows “that look out onto almost anything we want to”. We are fooled because these windows have blinded us to the fact that these heavy dark walls even exist.

The browser is a window out, but it’s a window into a fragmented and fractured city of rooms with no doors, no truly public spaces, a city of blind towers with no people…. An ever-changing city of windows looking into other windows….. a nightmare….I want to scream, I want to break down the walls and look out – but I simply don’t have the tools. I want to scream because even if I could break out I know there would be nothing to see – a city of blind towers, with its inhabitants constantly forming and reforming the internal architecture of their cells without ever really being able to break through and open up a real vista and engage in a truly shared experience.

My obsession is one of mass escape, an escape that would allow me to look at you – get a sense of what your doing, what your interested in… and most importantly lets me join you in a crowd. It’s an escape onto the stage of life.

Crowding is one of those acts of self expression that sorely needs attention in the online space, and until we can look out, and crowd in our public spaces then we will be forever locked and isolated.

Don’t tell me facebook, and myspace let me do this – they don’t. Don’t tell me I can be public by expressing myself in a window (via a blog like this), because this is not the kind of expression im talking about. Its not a reconstruction of reality (secondlife)….its not blindly shouting into the void via twitter….. its reality (or maybe the internet) – just not as we know it.

I visit bldgblog.blogspot.com obsessively, but it is a lonely place. This daily act is like carving on prison walls – its lets me define who I am but the only audience for this grand act is me. There is so much the reading community of this blog could give, what a crowd to join, what a place to see, what a fertile place for a culture to develop and grow… but how do we do this. I’m not talking about adding comments to posts. Its lonely because I know that every time I visit the site im actually sitting in a football size stadium along with 1000’s of other people. Its so lonely because not only is the stadium invisible, but so are the people its filled with.

What’s missing is the aspect of shared space that’s time critical, where its possible to have a defining moment with others, where because its possible to miss something (“no man, I wasn’t there”) its so much more special when you are “there”. Crowds are more about the number of people in a space at a point in time, sure lots of people can move though a space – but that not an event.

My experience of visiting sites is similar to watching a concert at home, by myself – with the TV coverage never turning its gaze back towards the audience. A concert where you cant hear or see the audience. Sure the music may be good, but give me a surging crowd, and a band that feeds off that crowd – and that’s a real shared experience.

So my badly formed vision of the future is connection via an interface that focuses on looking out, looking into the shared public space’s – the in-between spaces. An interface that expresses our movement in and around this public space. A browser not obsessed by destinations (URL’s), but one that focuses its effort on navigating and expressing the movement of traffic and expression of people positioning themselves in this space.

It’s a browser where its not the destination that counts, it’s the journey.

As the barriers between real and virtual space break down, and augmented realities and virtual overlays develop – then maybe, just maybe, we can develop ways to crowd, see, and be seen together in a more meaningful and engaging way.

The majority of the people I work with are expert problem solvers – and nothing gets a problem solver more excited than a chunky problem. I have to admit I probably fall into this category too… there is nothing I love more than to tackle architecting a great experience for a complex application.

In some ways this defines what I see as my value proposition “architecting online experiences that shoulder the weight of functional complexity in simple and engaging ways”

But here’s the problem – the chunky problems don’t always represent the most used or valuable aspects of the application for the real end users. These problems attract attention because they are rewarding to solve, and it takes a really focused business representative to keep the ship headed in the right direction.

I don’t want to turn this into another agile pitch, but keeping the business and development team’s close can help avoid this pitfall. The business should help direct eager problem solvers away from simply pursuing the most interesting problems, and guide the feature priorities towards maximum user / business value. It highlights how important the prioritization process is as you move through the iterations, so don’t get distracted by the chunky problems – get focused on the real problems.