UX Project Manager

UX London Day 3 Summary

This is a slightly belated post. I left the final day at UX London, headed straight to the hotel and was back on the train to Sheffield within 45 minutes thoroughly exhausted following 3 days of blowing my mind with a huge amount of knowledge and experience. I fully intended to write up my day 3 notes that evening but as you can imagine, getting home at 9pm on a Friday evening, and writing a valuable blog post was never going to happen.

So, here are my thoughts from day three that come with the added advantage of 12 weeks musing over the 2 workshops.

The morning workshop I chose to attend was ‘The UX of User Stories’ hosted by Anders Ramsay who’s keynote on Day 1 was the most relevant to me - hence it generating the majority of the notes in my earlier post from day 1.

The summary of the workshop included “There are few better entry points for UX Designers into the agile universe than User Stories”. This intrigued me as Project Manager running agile projects and needing to engage our UX Design Team into the project at the earliest opportunity. Traditionally, my understanding of stories has very much been that they are led by a Business Analyst creating and owning the stories, which has worked really well, but I definitely see the need for the UX Designer to be an integral part of defining the user stories and turning them into a realistic user journey that can be implemented.

“Stories are a to-do list for a set of users”.

In the workshop we started by looking at one of the problems with User Stories - that they are traditionally generated by asking the user ‘What do you want us to build?’ - this gives you a user solution that is optimised from a development perspective. What we should be doing is asking the user ‘What is the underlying problem or goal that you are trying to achieve?’ - this way, you will get much more of an emotional and contextual answer.

This is something that we have been feeding into our initial workshops with clients when they provide sketchy briefs and business requirements documents that are very much trying to suggest a solution rather than the problem. Only last week, @keeftango and I attended and ran a workshop that was all about defining the problem - the client had provided a Business Requirements Document that included requirements like - “Ability to be able to upload a news feed to the site.” - Now we could take that and create a solution to be able to upload a news feed but in the context of the project, we really needed to understand what the problem is that they are trying to solve by uploading news feeds.

The remainder of the workshop consisted of us working in groups, trying out a number of techniques for developing User Stories. Below is a list of the ones we covered. I will be looking at them in more detail to see how they could add value to the projects I am running.

• Experience Mapping - Aimed at establishing the users goals - what they are trying to achieve starting with the whole experience from the start of their journey to the task they are there to perform.
• Pair Interviews - Observing 2 users interview each other - this is an alternative to interviewing them directly - leaving you with more time to capture the users aims and frustrations.
• Agile Personas - When writing up the personas, focus on what differentiates them from an ‘average’ user.
• Relating Personas to Stories - Use the personas when writing the stories - instead of ‘As a user…’ go with ‘As John…’ - this will help focus the stories on the users, and not the functionality. The functionality will come later when the stories are broken down.

The last one gives stories that are heavily focused on the users. So, how do you convert these stories into tangible functionality that the development team can start to work with? The answer is Sketching.

Taking each of the stories and working with key stakeholders to sketch out the different ideas for how the interface should achieve the story will drive out the functionality. The stories can then be broken out into detailed functional requirements. At this point, it is extremely useful to involve the development team, as well as the client. With these parties present, the ideas generated can not only be understood by them but can also be validated against the clients scope and have technical due diligence applied.

This is actually a technique that @keeftango has been running with on a major project that I am managing. We started with a set of user stories which we have split out into phases / sprints that each start with a sketching workshop that includes the client sponsor, and the technical architects for two 3rd party technical development teams. This has proved invaluable in order to generate the ideas and direction that we are then using to develop a fully working prototype. I will post more on this as the project progresses but so far, we are reaping the benefits of going through this process and we have an extremely happy client who is now fully engaged with the process.

After lunch - the final workshop of the conference. This one was a choice based on a recommendation. As soon as we saw the programme for the 3 days, @belaybunny and @keeftango both pointed Leisa Reichelt’s workshop out as the one to go to. It was titled ‘Strategic User Experience’.

Straight away, Leisa started by ensuring we were all clear of the difference between ‘Strategic User Experience’ and ‘User Experience Strategy’…

User Experience Strategy = Thinking and talking about UX

Strategic User Experience = Creating a better environment for doing better UX

Leisa talked about how most organisations waste time talking about UX and not doing UX. The process should be bottom up, not top down. This is something that I have definitely seen a swing in over the past 3 months at work - having put in months of hard work selling our User Experience led approach to projects, we are now practising UX techniques on a daily basis, refining and learning as we do. This is feeding through the whole company with more and more projects taking a UX led approach.

Unfortunately, I missed most of the remainder of the workshop due to an emergency at work that needed to be sorted before the weekend - so I was in and out without really getting back into it. I did however take away a number of things to look into / read:

• Simon Sinek - http://www.startwithwhy.com/
• Peter Drucker - http://druckerphilosophy.com ‘The customer defines the business’
• Gamestorming - http://www.gogamestorm.com/ - This is a book I have already read and put into practice - highly recommended if you need to facilitate the process of defining things like requirements, aims and stakeholders for a project.
• The KJ Method for prioritisation - http://www.uie.com/articles/kj_technique/

So there it is, my round up of UX London 2012 - hope it has provided some insightful thoughts and pointers for any of you also finding your feet with UX. As promised throughout, I will keep updating this blog with my thoughts and experiences.