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!

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?

I saw the One Less Drop product showcased in my RSS feed from DesignSpotter, and loved it immediately (yup, I’ve joined the pre-order list!

What I liked even more was the video that the designer made about the design evolution of the product:

Wikipedia defines a symposium as “a drinking party (from Greek sympotein, ‘to drink together’)”, so I’d like to start by stating that, while I’m a big fan of drinking together, this is not what I’m referring to! What I’m referring to is the format, often taken in the academic world, of meeting to discuss and share ideas around a particular theme.

So, what does this have to do with user experience?

I work in a large FTSE 100 organisation, but regardless of size, as a UX person in an organisation one of the biggest headaches is sharing your work with everyone that feels they have a say in what you are doing (and that’s generally a long list). Sharing work is definitely not a bad thing – getting a broad spectrum of people giving you feedback gives you interesting and different perspectives.

However, were you to individually sit down with everyone that asked to see/feedback on what you are working on, you would spend 99.7% of your time taking people through the work you’ve been done, and the remaining 0.3% of your time evolving it and/or moving on to the next thing!

A technique that I’ve used, successfully, is to hold a symposium. We take over a large room for half a day, and stick all of our work on the walls. We then invite as wide an audience as possible to pop in at any stage during the symposium, and have a look at our work.

We present the various streams of work as areas on the wall, where deliverables are shown, and the person/people who worked on them are there to talk people through the posters, answer question and gather feedback. These ‘station’ type areas could be at a page level, or present the results of some research.

I believe that there are a number of advantages to this format:

More

This book arrived in the post yesterday, and I love it!

David McCandless has taken lots and lots of very interesting data and turned it into a thing of beauty. It’s not just beautiful, it’s intreating, informative and inspiring. Taking such a complex data and creating beautiful visualisations.

Early this summer David spoke at TED, showcasing some of his visualisations and giving us an insight into his motivation and inspiration.

I hope you enjoy it as much as I did!