Collaborative Design Facilitator Cards (First Iteration)

So I am on the verge of running yet another collaborative design workshop and decided to create a set of facilitator cards.

This first iteration is rough, but will do the trick for now. They combine different techniques together into what I hope is a clear linear workshop process. Will try and create a more refined set once I test using them a bit.

Download the draft set as a PDF : CollaborativeDesign_FacilitatorCards

 

Posted in Uncategorized | 4 Comments

realestate.com.au iphone application

Delighted to see the REA iphone app launch to great success. After a week it is…

  • Rated 4+ stars
  • #1 in the Top Free Lifestyle Apps Category
  • #19 overall in the Top Free Apps Category

It was a delight to work as the Experience Designer on the project. The Devs (a mix of ThoughtWorks and REA) are guns, and i can really only take partial credit for the design – it was a truely collaborative effort between Dev’s, the Business, and 😄 (Me and Matty D on graphics)

Also a quick time lapse from my desk showing agile paring, the card wall, and how closely we work together at one big desk.


Posted in Uncategorized | 5 Comments

iPhone sketch template

Created these yesterday. Caring is sharing…..

 

 

 

 

 

Posted in Uncategorized | 4 Comments

XD across mulitple enterprise systems

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 😄 across multiple enterprise systems” from Lindsay Ratcliffe was no doubt off the cuff – but it’s a great summary of how to approach large 😄 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.

thanks Lindsay

Posted in Uncategorized | Leave a comment

Creation of a diagram in a day (Experience Design : From Strategy to Delivery within the Agile Product Delivery Process)

A post partly about a diagram that expresses the way 😄 plays from strategy to delivery, but mostly about the generation of a diagram in a day.

Creation of a diagram in a day….

1. Figure out what you are trying to express
I spent 2-3 hours working up this crazy mess in order to figure out what i was actually trying to express. Didn’t worry to much about polish – more focused on the message and how the diagram was going to support the message. Played a bit with drawing little descriptive pictures that helped support the ideas.

2. Use this as a base for laying out the real diagram
I then focused on laying out the diagram more neatly. A combination of first redrawing the overall structure and also literally tracing bits and pieces of the previous diagram. For safety sake, i scanned the drawing at that point. (which turned out to be a very good idea)

3 – Applying colour (the failed attempt)
As you may have guessed i am getting into using my new grey and yellow markers. So i attacked the diagram with gusto… and didn’t really dig the results. Unfortunately the paper quality of those giant post-it note sheets is crap – the black, grey and yellow all bleed together and the diagram was to big to hand colour in the background grey. Bit depressed after an hour of hand rendering.



4.  Applying colour (thats right, i can use a computer!)
Just threw the scan of the raw sketch into fireworks. ahhhh – thats better…. Only took an hour or so to apply the colours.


5. Laying out the supporting labels and text
I spent the rest of the afternoon laying out the text defined in the initial sketch and polishing the graphic design. The results are below… i might do a post later on the actual message of the diagram (probably more interesting than how i created it)



Posted in Uncategorized | 2 Comments

Business Model Canvas – Facilitator Cards

I have created a set of facilitator cards to help run Business Model Workshops. Defiantly worth printing a set if your going to run a session. Forgive my crappy handwriting !

Download the entire set in the attached A5 pdf – Business_Model_Canvas_Facilitator_Cards

I need to explicitly state that this is not my method, I am just a big fan of using it. All credit goes to Alex Osterwalder and the gang at http://www.businessmodelgeneration.com

I have previously posted about the process of using the Business Model Canvas – https://jasonfurnell.wordpress.com/2010/10/14/so-whats-the-business-model-the-business-model-canvas/

A preview of the cards are below – the back of each card has notes to help guide the activities.

Posted in Uncategorized | 8 Comments

Sketching, Sketching, Sketching

really enjoying sketching… thought i would just post a few small examples.

 

Posted in Uncategorized | Leave a comment

Facilitating Collaborative Design Workshops – a step by step guide for rapidly creating a shared vision for execution

So how do you do great design in a rapid, multidisciplinary and inclusive way?
How do you set up new projects for success in a fast moving, agile environment?
How do you ensure shared understanding and ownership of new initiatives in just a few days?

I now focus a lot of time on facilitating collaborative design workshops, and other methods focused on quickly creating a shared understanding of objectives and buy-in for and execution approach.

In my experience if you set up a new project well a good team can then pick up the ball and run with it. On the other hand, if a project has a wobbly start – with a lack of vision and differing understanding of the objectives – then even the best team can be doomed to failure.

So before i bore you to death talking about it, i will start with a timelapse video of a Collaborative design workshop showing the kind of thing i am going to talk about.

Below is a photo of the core team discussing the final Sketchboard. Its worth noting that there are also priority and sequencing notes – so its a definintion of both what to build, and how to go about it.

So whats going on here?

  • 0 sec – Introduction
    Firstly me, recapping where we are at, and the structure of the upcoming 2 hour workshop
  • 7 sec – Teams sketching designs and page flows
    for a different part of the application in parallel. One team on each table, with a mix of Technical, Business and User Experience stakeholders
  • 15 sec – Starting to Construct Design Sketchboards
    each team has a wall and starts constructing the sketches into flows and processes
  • 30 sec – Sharing back progress
    and gather feedback from the rest of the group
  • 55 secConsolidating the designs
    first deconstructing then reconstructing each of the sketch boards. Walking thru areas that need further refinement or development, and using the walls to plan activities in the next round of design

Whats the output?

Again, before I smother you with the detail of how to do it, I will start with the typical output of 3-4 days of collaborative design workshops. This example was part of a 2 week build Inception. The output was used to drive technical story writing, estimation and planning for agile build phase.

The outputs

  • Business Model Canvas
    a definition of who our customers are, what value we will be delivering to them, and how the business will deliver this value – framing the business drivers / objectives and resource required by the project.
  • Customer Journey Maps
    exploring typical journey customers will experience when attempting to extract value from our services. Their motivations, goals and fears and how these define “moments of opportunities” in their journeys. Or more simply, “How might we…” add real value for our customers.
  • Design Sketchboards
    a way of translating “How might we…” design challenges into design solutions. A sketch based method for rapidly developing and sharing design concepts. In the end, its the Design Sketchboards that are the real deliverable of these workshops. They represent a great starting point for either writing stories for estimation, or as a clear brief for a UX designer to develop an interactive prototype for customer testing and business validation.

Ok. lets look at the process

1. Kicking Off

If your gathering 10-15 people together for workshops, taking 50% of their time for a number of days then your asking for a big commitment and YOU BETTER HAVE A PLAN!

You need to be clear about when they need to be there (i use 2 x 2 hour workshops per day), what process they will go on (sample assets always help) and most importantly a strict and clear shedual of activities and timing for each activity. If your going to work them hard, then you need a whip. Having a plan is the whip.

Pre-planning the teams is also a good idea in order to ensure a good mix of disciplines. A sample 3 day workshop agenda is shown below.

2. Understanding the Business Objectives and Drivers

I use the business model canvas, objective statements and other fairly standard inception activities to drive out a shared understanding of the Business Drivers. If your staring an inception workshop there is a good chance there is someone standing there with a bucket of money and some expectations. Its good to start by understanding what these expectations are. I have posted about the business model canvas before – so wont go into to much detail here.

Below is a time-lapse of me facilitating the session. What i think is clear is you need a clear, predefined structure, plenty of wall space and (this is the hard bit) the ability to rapidly make sense of the flow of post-it notes that are developed during the session.  I have created a set of cheat cards to help facilitate these sessions. A link to the PDF is available below.

Business_Model_Canvas_Facilitator_Cards

3. Understand the Customer Journey

Mapping out the customer journey lets you understand the real world experience for your customers, and describes the context within which your service will exist. Below is a timelapse videos of a customer journey session.

The basic process (and time stamps within the video) are …

  • 0 sec – Introduce the activity
    i find starting with a blank template on the wall helps
  • 8 sec – Define who you are focusing on
    split into teams and develop personas, motivations fears and goals. We developed our personas using data from previous user testing participants.
  • 15 sec – Share back your personas
    Add you notes to the wall, share back
  • 20 sec – Map out the journey
    You need to have start and end points for the journey (in this case i created these before the workshop started). Get each team to map ou the tasks, steps, phases, transitions, touchpoints… anything that describes the customer experience
  • 30 sec – Share back to the group
    Share back where they think they can effect real change or add value
  • 35 sec – Identify moments of opportunity
    Get each team to map on emotions, moments of truth, pain pionts, etc and identify where you can effect real change or add value
  • 40 sec – Extract out Design Challenges
    Translate moments of opportunity into design challenges, and map these onto the journey. In the video these are the white cards above all the post-it notes. You then need to prioritise the “how might we…” challenges and  decide which ones you are going to tackle in the next phase.

Output – before and after images of the Customer Journey Template in use


the value in developing customer journeys two fold

  • The “how might we…” design challenges are an excellent design brief for the next sketch design phase. The process ensures that you have coverage across the entire journey – not just focusing on one small (and usually hard to implement) part of the application.
  • You get shared understanding of the context – an understanding of the technology solution in the context of a real life person, doing real life things, with real life motivations, fears and goals

4. Design the experience together – using a design Sketchboard

Design Sketchboards are a place to explore flows, sketch ideas and collaboratively build up a vision for the experience design for key area’s within the service. I was first introduced to this way of working via Leah Buley and Brandon Schauer from Adaptive path. Much of what i describe below is based on their method, as are the 1 up and 6 up templates.

http://www.adaptivepath.com/ideas/essays/archives/000863.php

http://www.adaptivepath.com/images/publications/essays/sketchboard/ap_singlepage_sketchboard_templates.ppt

http://www.adaptivepath.com/images/publications/essays/sketchboard/ap_multipage_sketchboard_templates.ppt

As the name suggests it requires people to sketch. Now you may think this is challenging for some people, but all you need to do is give them the right tools and train them up a bit. If you can sprinkle UX’ers or other people you know who can draw around the teams it helps.

Again, i have Adaptive path / UXweek 2010 to thank for reminding me about getting back to basics with drawing. There was a time when i simply thought sketching was a waste of time (i could do it a thousand times quicker in fireworks, and generate interactive prototypes really quickly) BUT what I missed is the shared, team aspect that getting everyone to draw brings with it.

learning to draw – Tool up and warm up
Moving from chicken scratches, to what looks like professional sketching is mainly a matter of tools and process. The tools you need are a range of good quality pens and markers – see below. the process is basically :

  • Use the 1up and 6up templates – it build confidence
  • start drawing with the thinest pen (this is where most people stop)
  • give the drawing structure with the thicker sharpie
  • push areas forward and back using the grey marker
  • highlight key areas with yellow

to warm up start with drawing boxes, then move to practising drawing some fictional website homepage.

examples of pens, and outputs of warmups exercises below

Have a look at the video’s, everyone is drawing – I hardly ended up drawing a thing! (well… i helped the teams throughout the process and often leaped in to quickly sketch up areas they were having problems with)

Below is a timelapse video of setting up and using a Design Sketchboard.

The basic process (and time stamps within the video) are …

  • 0 sec – Introduce the activity
    Basically assign each of the teams design challenges, and introduce using the 1 up and 6 up templates
  • 5 sec – Exploratory Sketching
    Identify key pages or moments within the service – Generate at least 6 different ways to approach the problem
  • 10 sec – Start structuring the Sketchboard
    Pasting up design options and sequencing page flows. Draw the flow: How do you get from one screen or state to the other? Add it to the sketch board
  • 15 sec – Share back
    Select and build on the best approaches together.
  • 20 sec – Refinement Sketching
    Back into teams and develop one or two of the selected options in more detail using the 1 up templates
  • 37 sec – Constructing the Sketchboards and sharing back
    It’s about making it shared, concrete and tangible. Select and build on the best approaches together. Refine the structure and content of the sketchboard in order to set a clear direction for the Customer Experience
  • 58 sec – Consolidating the designs
    Its worth taking some time after sharing back to clean up and restructure the Sketchboard in preparation for the next round of design.

its worth noting that we brought in a end user (stole them from some user testing) and i got each team to present their designs. I was a very health check point and forced the teams to clarify what they were trying to do, and to quickly find a way to express it.

Output – an photo of the final consolidated sketchboard, and presentation of the work to a wider set of stakeholders


5. Next Steps

Sketchboards are a just a jumping off point for :

  • Customer / Business Validation
  • Experience Prototyping
  • Story writing and estimation

You need to be confident that you have done “Just enough” in order to ensure you have :

  • Explored a range of ideas
  • Selected and built on the best ones
  • A vision for execution that is clear and shared

I hope this helps you in some way. I have run a few of these sessions and while exhausting they can be very effective and the tech and business people love them. Once you stop working in isolated “expert” mode (the default for most UX’ers), and start working collaboratively its hard to turn back. Its simply a more effective, faster and more satisfying way to work.

Posted in Uncategorized | 37 Comments

Envisioning v’s Inception

Envisioning is not BUFD, but it is a (lean) phase that proceeds inceptions in some cases. The real diference between envisioning and inception is they have different objectives.
  • Envisioning is about developing and testing the customer proposition for a new service, usually by developing a prototype that expresses the value proposition and tests execution concepts. Another difference is that envisioning is a key asset driving the business case, the thing that allows the build team to have the freedom that comes with a bucket of money and a heap of trust.
  • Inception is about developing a shared understanding of the business objectives with the entire development team, and building a delivery plan for execution. it happens after the business case has been approved.
Posted in Uncategorized | Leave a comment

Agile demands that you get closer to your customers

An argument (using the agile principals as a base) for why software teams need to get closer to their end users / customers

Individuals and interactions over processes and tools
so…. you have built a few insurance applications in your time – but how many times have you actually seen the end users attempt to use this software. How many times have you sat down with the end customer, talked about the real world context in which they use this application, identified what problems they are having in using it and THEN iterated the design of the application in order to ensure they can actually extract the kind of value they need out of it. Is this kind of quality control (ensuring the end users find the application valuable) done EVERY iteration?

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)

flame 1 – if you havent personally user tested your application with real users in the last iteration then your relying on processes and tools to shield you from the reality of end customer needs, motivations, fears and wants. dont blame the business – blame yourself.


Working software over comprehensive documentation
im going to preempt your responseyour going to play the “Working software over comprehensive documentation” card, insist that the best way to service the end customer is to build the minium viable product and get it out there as quickly as posible, then get real feedback and iterate. Again i have to agree furiously in principal, but challenge your real world practice.

😄 is all about trying to understand the customer, and what the minimum viable product in fact is. 😄 is all about trying to get real feedback from customers and iterate by spiking the experience early, failing fast and failing cheaply in order to avoid late, massive and costly failure.
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.

flame 2 – if you havent spiked the experience using working software, tested then iterated in order to better understand the minimum viable product then your not really iterating – your just incrementing (thanks to jeff patton for that one:)


Customer collaboration over contract negotiation
ok… so this is where we get to argue about the definition of the word “customer”. 😄 suggests that you CAN’T rely on the product owner to act as a proxy for the end user. you may want to argue this “proxy” is just fine…. but i disagree.
Its difficult to find the balance between end customer and business needs when the product owner is the campion of both. Engaging with both real end users and business owners is a better way to understand these often competing needs. We should actively facilitate this exploration.

flame 3 – if your relying on a “proxy” for the end customers needs then go and read flame 1 again


Responding to change over following a plan
😄 takes this so seriously we in fact try and drive change. We attempt to challenge the business assumptions and hypothesis by testing them, iteration after iteration – so that we ensure delivering maximum value (not just maximum through put). If we discover that we are infact “building the wrong thing” then we attempt to drive change. Its not about blindly building what you descide within inception. its about getting feedback early, iterating and delivering real value.

flame 4 – if you have just blindly built what the product owner wanted, and the application is crap and you know it – then go and read flame 1 again.
Posted in Uncategorized | Leave a comment