I work with my team to continually look for better and more effective ways of working. I’m a big fan of agile and iterative practices, but without a dedicated Scrum-master, it’s pretty hard to do full agile, IMHO. Over the past few weeks I’ve put together the following process for a UX and Design team to work to.

It incorporates many techniques that I think are vital to successfully delivering work:

• Collaboration
• Iteration
• Regular reviews
• Stakeholder input
• Regular reviews (both with the team and with stakeholders)
• Sketching
• Prototyping
• A style guide

This process was built around not having direct access to developers – so it  needs to sit within a wider Waterfall process, with a handoff into the development cycle.

The Process

1. Project initiator(s) work with UX to:

• Articulate the business needs/requirements,
• Articulate the user needs/requirements,
• Articulate supporting research (where applicable),
• Commission additional research, analytics support etc.

2. Project group assigned, which includes:

• project initiator(s)
• UX,
• Design,
• Test,
• front end developers,
• back end developers,
• architect(s),
• project manager,
• business analyst,
• content/editorial,
• business representative(s) as applicable.

3. [ KICKOFF ] Carry out a Design Jam for the feature:

• UX presents research and frames what the objectives are,
• Group breaks into smaller, multi-disciplinary teams,
• Teams brainstorm and sketch:
  • user journey/flow
  • pages and components

4. UX refines and elaborates the user flow and sketches.

5. [ ITERATE ] Sketches reviewed by team at weekly iteration review meeting.

• Team breaks down features as much as possible,
• Gives ROM (rough order of magnitude) estimates given for each story/task.

6. Milestone plan drafted and stakeholders identified (by UX and PM).

7. [ APPROVAL MILESTONE ] Sketches & plan reviewed by project stakeholder(s).

8.  [ ITERATE ] Agreed refinements as per Stakeholder feedback incorporated.

9.  Front end Developer works with UX to create a  prototype of the sketches.

10. [ ITERATE ] prototype reviewed by team at weekly iteration review meeting.

11. Informal user testing is carried out on the low fidelity prototype.

12. [ ITERATE ] Refinements as per testing incorporated.

13. Team reviews sketches/prototype in context of style guide (and component library), to determine how many new style elements and components are needed.

14. Designer begins works on new components needed for the project.

15. UX begins to create formal wireframes.

16. [ ITERATE ] Creatives & Wireframes reviewed by team at weekly iteration review meeting.

17. [ APPROVAL MILESTONE ] Creatives reviewed by stakeholder(s).

18. [ ITERATE ] Agreed refinements as per Stakeholder feedback incorporated.

19. [ DELIVERABLE ] Front end developer refactors low fidelity prototype (where necessary) and applies style to match creative design.

20. [ DELIVERABLE ] Designer updates style guide/component library. (The concept of delivering page level creatives is no longer necessary. We work on a style guide and update components, as necessary, and add new components as they are designed and signed off).

21. [ ITERATE ] Team reviews functioning feature/pages at weekly iteration meeting, ensuring that it meets the sketches & wireframes.

22. Testing carried out on functional (but not plumbed into the backend) feature/flow.

23. [ ITERATE ] Refinements as per testing incorporated and reviewed .

24. [ APPROVAL MILESTONE ] Final deliverables reviewed by stakeholders.

25. [ ITERATE ] Agreed refinements as per Stakeholder feedback incorporated.

26. [ DELIVERABLE ] UX creates detailed wireframes, documenting state changes and interactivity, and adds them to the component library. This becomes a primary resource for the test team, along with the user flow(s).

27. [ DELIVERABLE ] Style guide updated.

28. Front end developer works with backend developer to ensure that front end code is integrated as per standards, and that the same quality of code that was provided (by the front end developer) is being returned by the application server.

29. [ MILESTONE ] Project team and stakeholders sign off integrated feature.

30. [ ITERATE ] Team reviews pages/components/features as they are integrated into the back-end systems, and carries out user testing as necessary. Any changes as a result of seeing the integrated work is specified and scheduled.

So, I know that this is a bit of a brain dump, and I’ll add some rationale at a later point. But I’d love to hear any and all thoughts and feedback you may have. Have I missed something? Is there something that can be taken out?

Business Objectives vs. User Experience
http://www.smashingmagazine.com/2011/02/04/business-objectives-vs-user-experience/

Experiences are Emotional
http://johnnyholland.org/2011/02/03/experiences-are-emotional-2/

Are meetings broken, or are other problems being overlooked?
http://www.uxbooth.com/blog/are-meetings-a-broken-model-or-are-other-problems-being-overlooked/

UX Benefits to Building Mobile Web Apps
http://www.lukew.com/ff/entry.asp?1264Mobile Web Apps – Good for business but are they good for UX?
http://cvil.ly/2011/02/03/mobile-web-apps-good-for-business-but-are-they-good-for-ux/

Using Power Structure and Gestalt for Visual Hierarchy
http://sixrevisions.com/web_design/using-power-structure-and-gestalt-for-visual-hierarchy/

Designing a Reason to Come Back
http://johnnyholland.org/2011/02/01/designing-a-reason-to-come-back/

Inspirato Destination Guide
http://www.inspirato.com/Destination/Summary

On February 1st I spoke at the inaugural LightningUX event on the topic of how we, in the user experience community, speak to business. This is my attempt to try and convert my outline notes to a blog post.

User experience is a rapidly maturing industry, and now, more that ever, we user experience professionals are in high demand. Companies want a UX function, and say that they want to be more user focussed. However, much of the time companies have difficulty in fully realising the potential that our discipline can bring to the table. I think that we UXers also often struggle to get the level of authority that we feel we need, in order to successfully our user experience vision.

The question is: how do we change this? How do we ingrain ourselves more into ‘the business’ and get that magic seat at the table?

Use language that the business understands

99% of the time the people that sign off on budgets, be it project or departmental, are business focussed. They are finance people who have little to no knowledge of what we do, how we do, or why we do it. Indeed, it’s been my experience, that in corporate environments it’s not unusual for UX to be met with a degree of cynicism. That we magic up wireframes! That we conjure up designs!

Case and point is the resistance that we often meet when trying to get budget for research. A request often meet with replies like “Ask us, we know everything about  our customers.”, or even worse, “You’re the UX person – you should know all the answers, why do you need to do research?”.

To overcome this we need to show that we are on the same level as the business. That we understand their needs and goals. This is, I believe, how we will begin to overcome the impression that we sit in an ivory tower, expounding our user centric mantra!

This starts with the words we use.

The words we use are important

By framing what we do in business centric rhetoric we can start the process of convincing the business that we understand them. Now, I’m not saying that we don’t understand them, I’m just saying that we need to do more to convince the business of this. So that we move away from being seen as purists, talking in ‘fluffy’ terms about users’ needs and goals, and that we come across as the shrewd, business-focussed UX professionals that we are.

So, let’s start by talking more about customers (instead of users). And when we want to talk about improving the user journey , let’s talk about conversion optimisation. Let’s talk about persuasive selling, effective merchandising and presenting cross-sell messages as something useful to users (rather than the brute force approach many eCommerce sites take).

The words we use will reassure people that what we want to do has their best interests at heart. When we explain that we want to marry the needs of the user with the needs of the business, using business rhetoric, we subconsciously put the emphasis on the business side. It’s persuasion design and reassurance in practice! I’m not for one second saying that we shouldn’t use our own UX language, just that we need to frame it in a more business focussed vernacular.

The perfect mix for success

We, in UX, sometimes feel dirty when we start becoming more business focussed and use business-babble! That somehow we’re prostituting ourselves, a sullying the purity of our discipline. We’re not! When we talk about  a fantastic user experience, and putting the customer at the heart of what we do, framed in the language that the business speaks, we gain a new credibility. People stop and listen and begin to realise the opportunities that we can unlock for their business.

We’re also an incredibly passionate bunch of people, so committed to what we do. This passion, with our credibility, combined with our business focussed approach will take us to the next step of maturity as a discipline.

And as we develop our UX vernacular, framing it in a business speak, UX and Customer Experience will become a more integral part of every serious business.

So, along with credibility, there is another huge advantage to be got from crossing these two streams. We all look at the budgets that marketing departments have with envy, and lust for even a small part of that.As we become a little more business focussed, I believe that we will become as influential, if not more, as marketing is today, and will be given the budgets that we deserve. I could be provocative and say that as another plus,  we can  actually deliver tangible and measurable outputs! But I won’t!

On the back of this, one of the team here has started compiling a list of UX words and how we could business-ify them. Once we’ve got a critical mass I’ll post them here. Can you think any of the top of your head?

Thanks to Andy Birchwood for the use of the image of me speaking.

I’ve been posting a bit about the process of architecting the new online video on demand offering from Channel4. Well, it’s now live on channel4.com!

4od on Channel 4

I love this point in a project, when you see the fruits of your labour come to fruition and you get that sense of pride at looking at something that you’ve created and designed. It’s also interesting looking at the progression of ideas from the first sketchy wireframes to the clickable prototypes (which we tested with), the high fidelity designs to what is now live. While not everything that we had planned went in to this first release, we are really proud of what we’ve created here – I know that I am!

I hope you all enjoy the vast quantity and quality of content here – please feel free to let me know of good and bad things and things you think we can make better!

I recently gave a presentation about personas, and specifically how they can be used throughout a project lifecycle to ensure the highest quality. I thought I’d share that presentation with you. I’m a big fan of the approach to presentations advocated by Garr Reynolds in his book Presentation Zen. When I present my slides have no more than 1 – 3 words on them. That way people listen to what I’m saying. I also tell people that I am happy to share my slides and notes with anyone that would like them. My notes tend to be bullet points only, that way when I speak I’m not reading, I am working from my brain and it’s more of a conversation with the audience. This conversational tone is more engaging (I hope). Anyhow, on to the presentation!

Life before Personas

This is my vision for how life must have been for users before Personas came into widespread use. A barren desert with users wandering forlornly around the worlds of the internet and software. Stumbling around looking for an oasis of usability and accessibility!

It stuns me when I think that Personas really came into popular use after Cooper’s The Inmates are Running the Asylum. Things must have been (and were) pretty bad before that. Thankfully though, Personas are coming more and more into widespread use. There is still, however, some fear and reluctance towards their use.

Primarily this is down to the cost and time it can take to create them, and in some cases a failure to see the great benefits that they have. I think that we, as user experience professionals, need to be better at communicating their value and selling their uasefulness. Primarily we need to be able to demonstrate that the cost and time spent has far more value that just the Persona itself. More