I love this – what a fantastic and fun idea!

You can read the whole story here:
http://www.fastcodesign.com/1665227/simple-genius-a-panoramic-camera-you-can-throw-sky-high

5 Reasons Why Online Video Is So Persuasive
http://www.whatmakesthemclick.net/2011/08/24/why-video-so-persuasive-online/

Better First Impressions through Design
http://www.whatmakesthemclick.net/2011/08/24/why-video-so-persuasive-online/

The Hidden Business of UX Design
http://myddelton.co.uk/post/9284841195/hidden-business-of-ux-design

A Crash Course in the Neuroscience of Human Motivation
http://lesswrong.com/lw/71x/a_crash_course_in_the_neuroscience_of_human/

Quote of the week:

When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.

- Steve Jobs, Playboy, Feb 1, 1985

I saw this onMinimalissimo today – I love this simple and beautifully designed product – the MedaPhone.

It’s a ceramic horn that you put your iPhone in and it amplifies the sound from the speaker – simple! Definitely not one for audio purists though!

In case you don’t know, I look after the User Experience and Design teams here at TUI Travel, beside Luton Airport. We’re doing some pretty cool and exciting things up here, as part of a large programme of work. This work includes a complete overhaul of two of the biggest travel websites out there, thomson.co.uk and firstchoice.co.uk. What’s particularly exciting is that we, the UX & Design team, are playing a key role in setting, and implementing, the vision for these sites.

This vision is to completely revolutionise the way people book holidays. This isn’t just web, we are neck deep in cross-channel engagement and multi-platform delivery.

So, why am I wasting your precious reading minutes telling you this?

Having fun in the UX Playground

It’s been commented a few times that we’ve created a UX Playground for ourselves up here at TUI Towers! The comments have been prompted by the rich number of UX and Design techniques that we try and use here. However, the term UX Playground can be interpreted both negatively and positively.

Let me elaborate! I firmly believe in the need to employ a varied array of techniques, for both research and design. I am also convinced that you need to try techniques that you think will yield the best results for you (in the environment that you are in). Some of these may not work, others will.

The upside of the UX Playground

We do lots of different types of research, and we try lots of different types of research to get the best possible results. This is for three primary reasons:

1. We do research to get insight into customer behaviour.
2. We do research to give us a solid foundation for all design work.
3. We do research that provides us with the rationale and justification for our design decisions.

Digital Diary Study Entries

We also try lots of different design techniques, again to get the best possible results. Sometimes that means going back over work, trying a new approach and seeing if we can make it better. This isn’t gold plating, but if we have any doubt about what we’ve done, a new approach gives us a fresh perspective on things. And we always refer back to our research.

The positive side of this is that the team gets lots of exposure to new and varied research and design activities. Some which, in other environments, you may not see very often. For example, we are currently in the middle of a digital diary study, where participants post to an online diary; but we’re also using postcards as an extra dimension to this. We’ve researched and created a mental model and done some really exciting emotional response testing.

Our design process involves varied techniques too. From Design Jams involving people from all around the business, to collaborative persona needs and user journey creation sessions.

This is great fun. Exploring new ways of getting insight and new design techniques. It’s interesting, it’s varied and, most importantly, it’s productive.

It allows us to most effectively deliver the best results to the business.

Dispelling the negatives of the UX Playground

Brainstorming Persona needs

There is a negative connotation that could be inferred from the term UX Playground (and I’m in no way saying that the people who coined the term meant it in anything other than a positive way!). There could be a perception that we are just trying things out for the sake of it.

Let me refute that now: we’re not! Everything we do is to give us the greatest insight into customers, and to allow us to deliver solutions that afford the maximum competitive advantage to the business.

When we try new techniques we look for the most cost effective way of testing them. If the results yielded are good, then we invest a more, as long as that investment is returned by a tangible business insight and benefit.

My advice: create a UX Playground

If you can, I would advocate creating a UX Playground. An environment where research is an integral part of the process, and where new research methods can be freely explored (in a cost effective and timely manner).

Create a UX Playground where new techniques for collaborative design are explored. Where Gamestorming concepts are used with the business, so that these sessions are fun for all involved.

By making things a little more fun, we become more creative; we make it more engaging for non UX and Design collaborators; and create an workplace that fosters the premiss of trying new things, an environment where innovation is the norm.

PS: if you’re interested in helping us to revolutionise the way people book holidays online, and having fun doing it, drop me a line (alex <dot> horstmann <at> thomson <dot> co <dot> uk) – we’re always looking for great people to come and join us here at TUI Towers!

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?