Apologies (Martin) for the blatant attempt at secondary brand association in the title, but i cant resist talking about a lunchtime chat I had with Martine Folwer (co-author of the Manifesto for Agile Software Development), Diana Adorno and Luke Stubbles on Experience Design in an Agile Context. Sometimes ThoughtWorks is a cool place to work.
Notes from the discussion points below…
Continuos Research – Pursue qualitative guerilla usability & market testing, hand in hand with quantitative real world stats and behavior analysis
Collaborative Design – Pursue inclusive, multidisciplinary sketch based exploration. Include the consumer in the process
Rapid Prototyping – Spike the experience, Build it once, then build it again. From sketch to working software. Dispose of throw away’s early – Get “in the medium” as quickly as possible (working reusable code, XD paring with Dev’s on prototyping)
Shorten feedback loops – Focus on the Minimum Viable Product, and the experience progression across releases. Aim for an early release, learn from real world usage. Continuos Research. Designers need to “keep their head in the clouds, and their feet firmly planted on the ground”. Never loose site of the Immediate Delivery – the things real consumers are going to use first.
Just enough, Just in time – XD in an agile environment. Getting away from the deliverables game. Influencing the build, creating empathy for the users, continuos testing and iteration (truly iterative, not incremental). Just enough precision for estimating early, then just in time design decisions for execution. Its not easy but you need to maintain a tactical shot horizon vision (whats being released next) and a strategic long horizons vision (all this effort is heading towards this…)
Design Thinking and Visual Communication – Within inception and beyond.Focus on the narritive and context – often missing in agile projects. Remember stories are a planning tool, not a design tool. Design Sketchboards, Customer Journeys, other visual meeting and communication methods – the INVEST story is cannot be the primary design asset.If you start a project (after inception) with a massive card wall, and have successfully cornered the business into prioritizing a set of feature stories BEFORE spiking the experience in a prototype – then your in fact relying on abstract documentation rather than working software to define a products vision.REAL individual interactions – facilitating consumer participation in the development process. A subtile shift from including the “customer” to including the “consumer” in the build process.Come on…. are you really having REAL individual interactions with the people your building software for on a regular basis (im not talking about your product manager)…. are you relying on processes and tools (like a dodgy persona done in one hour during inception, or saying you have got feedback from your customers in a one hour showcase that is not really structured to illicit feedback, but rather report on progress)
Business Process Visualisation. XD may have a real role to play in visualizing analytics and designing data visualisation graphics for complex “invisible” information. If you hear the words “Business intelegence” get involved and add value.
Experience Design is a quality issue. XD need to get better at articulating the quality benefits (which we all agree are there)… better execution, identify the tangible effects on speed and quality of execution.
Agile XD Transition requires people on the ground. its easy to make an argument for how bad Big Up Front Design is, but what hard is that once you recognize that isolated upfront “expert” design is bad, you then need to accept that you are going to need a XD focus THROUGHOUT the entire build process. To pursue Continuous Design, an embedded, continuos and integrated practice you NEED people on the ground.
Agile XD Mentoring within a consulting model. This is a problem that may be particular to ThoughtWorks, but we talked a lot about how you ensure growth, sustainability and mentorship in XD when client demand does not encourage XD pairing. Without pairing the apprentice professional development model fails. Without some sort of “design studio” environment its difficult to develop skills depth (although we recognize the existing model is great at promoting skill breadth). A few idea thrown around were:
- 1/2 day design studio gathering per week – pitching it to clients as “just the way we work here”. Sharing design issues and techniques – focused on real world client projects
- XD buddy system – someone you can bounce things off (even if they are at a different client)
- Pursing a proactive community – meetings and events outside of client hours
- Paring (without demand for 2 XD’ers) – as more senior XD’er become poly skilled, then XD paring can be pursued with more junior XD resource being fulfilling the dedicated XD role, and the more senior person simply playing a more generic project role (perhaps BA or IM)… and yes i know its not about having specialist roles !