XD across mulitple enterprise systems

Reposting from http://jasonfurnell.wordpress.com/  Thanks Jason...

ThoughtWorks has a healthy community of people who you can ask random questions… and generally get a pretty good response.
This response to the question “Experience with planning XD across multiple enterprise systems” from Lindsay Ratcliffe was no doubt off the cuff – but it’s a great summary of how to approach large XD problems. Here it is…. (thanks to Lindsay for letting me post it)
“Map out the existing customer experiences across all the touch points relevant to the systems that you are rebuilding. This scale of project can be somewhat daunting but is an excellent opportunity to really affect the total customer experience. Often when experiences are just looked at from a single product perspective the overall experience becomes disjointed and ugly because no-one is looking at the big picture.
Not sure if it’s on the same sort of scale but I was involved in a project at a bank where they did a review of their product portfolio and discovered majority of their customers only had 1.3 products (average metrics obviously). So they went on a drive to ‘increase a share of wallet’. ‘Products’ actually were as simple as:

• An single bank account
• Access to internet banking
• Access to telephone banking
• A card with their account (debit or credit)
• etc..

Each product was built in a seperate legacy system and so as soon as you started to draw out the experience that a new customer to go through just to open a single bank account you immediately saw the pains. Seperate forms for each ‘product’, having to repeat personal information on each form, dependancies between products, lags opening some products, different ID requirements for different products. Urrgggggh it was just all too hard, which actually meant that it was then quite easy to make what seemed like small improvements but that had massive positive impact.
So start with the usual stuff:

• Looking In: undertstand the end customers – sketch out personas that include wants, needs and desires
• Make a list of customer goals – what are the customers trying/desiring to achieve during their interactions
• Map out the existing customer experience – identify where/what the pain points are, where the moments of truth/happy moments are, where the waste is, where the opportunities are (this can be done collaboratively. Do it with the business and get their perspective. Do it again with customers and get their perspective, especially as they won’t give a hoots about technology.
• Looking Out: look at the competitors and other organisations who may not be competitors but have a similar structure and see what the customer experience is like there.
• Analyse the findings from both looking in and out to find out where the true insights are
• Use the as-is state and the insights as a spring board for ideating around the ideal state (again do this collaboratively to get the best results)

The deliverable doesn’t have to be anything more complicated than a big map of the ideal customer experience across the products and systems. This provides a vision of success and a framework for rebuilding that is based on value to both the end customer and the business.

Haste makes waste

I watched “The Killer in Me” a couple of nights ago and I’ll save you time that you’ll never recover by saying don’t bother. IMHO it was pretty awful. However I will give it credit for the title of this blog, "Haste makes waste," as it summarises perfectly what I want to say here.

I was privy to a large debate about new features and enhancements for a critical internal application. One user-friendly person offered up the suggestion that instead of just collecting a bunch of features and requirements that someone should take the time to do some quick wireframes and then do some guerrilla-style testing with a handful of users. Seemed like a sensible idea to me. However it was met with the following (paraphrased) response:

‘I beg you not to design and test before coding – get coding as quickly as you can and if it doesn’t work change it. The idea of UX before code is outmoded and needs to change…’

Actually what is outmoded is building software that is bloated with features that are either not used, not wanted or are so unusable that they are not used. Coding from a bunch of business requirements without considering the overall experience produces exactly this kind of ‘bloatware’. I do subscribe to the notion of getting to code as quickly as possible and that big-up-front design is wasteful but answer me these two questions?

Question 1: How much time would it take to build a working application (even in Ruby-on-Rails or the like) with fifty or so fairly critical features?

Answer 1: from a random poll of devs, the finger in the air answer was 2 x 2 pairs of dev (4 people) 6 weeks for the minimum critical features.

Question 2: How much time would it take to rapidly, or even better, collaboratively, sketch the application and get some quick feedback on what’s working and what’s not?

Answer 2: from a random poll of nearby UXers the finger in the air answer was 2 days to collaboratively sketch out the UI/user experience with users.

So If I follow the first path 1 I will have working software within six weeks (which IS cool, no doubt) but it will likely contain a whole bunch of stuff that when people see it will then say “ahh actually I didn’t mean that”,  “nope now I’ve seen it I probably wouldn’t use that feature”,  “I’m not quite sure how that (feature) works”, “now I’ve seen it I realised there is another feature missing that is far more important”… Which is all good feedback and allows us to iterate through the product development process. I have no problems with that at all.

What I do have a problem with is the muda, the waste. Why build stuff you don’t need, don’t want or doesn’t work?

In contrast if you rapidly and collaboratively sketch out the application in 2 days we get that same feedback 5 and half weeks of 4 developers time earlier and then when we start coding on day 3 we are much more confident that what we are building is not only the right thing for the users, with the right feature set but it also has a cohesive user experience, which is usable and useful.