Proposals

READ THE BRIEF!! Sounds obvious but you’d be surprised. Agencies who respond with well thought out proposals which respond to the requirements get invited in to pitch, simple as that.

Unless specified otherwise the basic format should be as follows:

• Executive summary (an over view of your understanding of the brief and asummary of what you’re going to do for them and how much its going to cost)
• Approach (The bit where you wow them with your exciting ideas for theproject)
• Methodology (how you intend to do the work. Keep it short!)- Timescales (when you plan on getting the work done and the stages involved)
• Costs (make sure you include *everything* including any expenses you might incur if you intend on recharging these.)
• The team (highlighting experience is a must here)
• *Relevant* work experience and projects
• Contact details

Cut down on the boilerplate. I come from an agency background so I know how easy it is to pad out a proposal with boilerplate but believe  me when you have to wade through multiple 30 page proposals full of guff you soon lose the will to live. Keep it short, keep it to the point, make it easy to read (top tip: bullet points are your friend!).

Remember that if this a proposal for a larger project then its most likely going to be seen by quite a few people who will have to fit this around their day to day work so make this task as easy as possible for them. They will always skip through to the Approach and the Price first then if you still have their attention they’ll read the rest of the proposal.

Trim the processes waffle – As a client I have carefully chosen a select few agencies to send this brief out to based on recommendations, past experience and your website. I’m assuming a basic level of competence to deliver a project so no need to bang on about your processes which will inevitably get dumped as soon as you start on the project.  Besides which your Creative Processes are all the same as the next agency – you are not unique in your approach!

Mention it sure, but I really want you to tell me about your ideas to make this project amazing and how you are going to go about it.

Don’t sell yourself short! – If its not already listed in the brief ask for a ball park figure for the budget and estimate the project around that. Generally speaking the client will have a set amount of money allocated for the project and thats what they will expect the estimates to come in at (+/- 10%). You won’t win the work because you’re cheap; it just makes the client suspicious of the quality they will be getting. They would rather the product you are working on exceeded their expectations therefore winning praise from their superiors than saving a few pounds.

Include bios and case studies. Especially if this is a new client. They want to know not only who you have worked with but also some short case studies around the project and how you went about it. They also are interested in seeing short biographies of the team that will be working on the project and their experience.

Don’t be shy about teaming up. If you don’t have the right in house people for a part of the job and its a requirement for the brief don’t try and bluff your way through it. Partner up with someone to do this bit of the work and be honest about that. Theres nothing worse than reading a proposal written by someone who obviously has no idea what they’re talking about. UX is a prime example of this.

Cut the Bullshit – This is a biggie. Don’t try and lie about experience or clients that you don’t have or bend the truth to breaking point. The internet makes the world a very small place and you will get found out which will fast track your proposal to the bin and tarnish your reputation for ever.

Pitching

- Do your prep. When you are invited to pitch the client wants you to wow them with your ideas and how you intend going about implementing them so re read the brief, trawl their website for ideas and (if you can) ask the client questions to get more of an insight. When you are preparing your pitch expand on your initial proposal paying special attention to the approach and also include a relevant case study with a similar client and project. In the case study part talk about your approach and the journey you went on.

- Keep the presentation short. If you only have an hour don’t waffle on for ages, aim for 15 – 20 minutes. The client will most likely have a list of questions they want to ask you so leave plenty of time for them.

-  On the day. Don’t bank on there being projectors so have print outs of your slides. Also export your presentation to Keynote, Powerpoint and PDF just in case. Double check where the presentations are going to take place and arrive early. Normally the client will arrange all of the pitches to be on the same day so if you have a later slot expect over runs and that you will have to wait. Also if you are in a late slot expect the client to be a bit tired so try and keep your presentation to the point and lively.

So there you go, not rocket science but I hope you find it useful the next time you respond to a brief from a client.

Good luck!

The headline is that its been a roller coaster of a year with many ups (and a few downs!). But there is a bunch of things that I’m going to take away from my experience here which I’m going to share with you all.

As ever if you would like further info please do get in touch and if you’re looking for some Agile UX magic in your project from October onwards give me a shout!!

The focus of my talk was Agile UX from a UX persons point of view. I want to get people out of the mindset of lumping all of the UX work into Sprint 0 and for the UX person to ‘own’ the project from the beginning to the end. Its worth downloading the slides from Slideshare to get the notes so that they make more sense. In the coming weeks I’ll expand and explain a bit more about some of the concepts in the slides.

Not really UX related as such but having sat through a day of interviewing UX/IA freelancers yesterday I came away with a few of observations which you may find useful:

1) Don’t sit there quoting passages from UX books and studies It doesn’t make you sound clever, you sound like a parrot! Interviewers want to know what insight you can bring to the project not how many books you’ve read or conferences you’ve attended. Remember that the person interviewing you is unlikely to be a seasoned UX professional so won’t know what you are talking about anyway.

2) Do the research Its a bit obvious this one but I asked the candidates to take a look at the existing website and to offer some thoughts on how they’d go about improving it. I wasn’t after a full blown redesign just some comments. It was immediately obvious that some people had only taken a cursory glance at the site and others had put some real thought into it. The person who put the most thought into it got the gig.

3) Keep your portfolio relevant Time is short and Interviewers would rather see one example of a project which closely matches the work they want done and for you to go into some detail about the process and decisions that were made rather than a history of everything you’ve ever done. Also make sure you show some of the iterations of the wireframes and use that to illustrate the journey you went on.

So thats it. It was a nice to sit on the other side of the table for a change and I learnt a lot which I’ll be using next time I’m looking for freelance work. Has anyone else got any tips to offer?

Like it or not Sprint 0 is a well developed practice within Scrum. For developers its the time when they get to do all of the setup and prep work they need to do before they can start coding features and stories. In the bad old days of Scrum it was also the time when the UX part of the project got dumped. As a freelancer I’ve worked on a number of agile projects and been asked to produce the IA for a new website which has been shoe horned into Sprint 0 along with all the other UX deliverables. This approach makes life very difficult for the IA as they often have to work with an undefined set of requirements and quite often its also the last time you see these wireframes before they get pulled apart and turned into user stories for the backlog, changing beyond all recognition as the project develops.

We decided against taking this approach for the BFI redevelopment project and opted to treat UX the same as dev in Sprint 0. Getting all the initial user research done ahead of starting the project proper  would help the IA and design process when we move into the development phase with the IA getting developed in conjunction with the development effort. In case you’re interested our Sprint 0 lasted a couple of months.

Here is a list of the work we did, roughly in order. YMMV:

Personas – As with any other user centred design project the first place to start is with the initial user research and getting personas developed. If you only ever take one thing away from this post then make it this. In an Agile UX environment personas are worth their weight in gold! I’m sure you’ve worked on projects in the past where personas have been tacked onto the side of a project as an after thought and never used again. However in an Agile world where the backlog and user stories are constantly being validated and reassessed having personas to sense check these decisions against is invaluable.

The personas were designed in the normal way and amongst other things we’ve used them in this project for:

• User Journeys (more on this in a bit)
• User Stories (the bits that make up the backlog)
• Recruiting participants for user testing
• Team building (I’ll tell you about this in a further post!)
• Backlog Prioritisation (more about this here)

Site Map – Before we could start writing user stories and looking at the first Sprint we had to develop a site map. All of the UX deliverables we have produced are flexible and are based on our knowledge at the time, they may (and often do) change over time and the site map is no exception. To date its been through 9 revisions as our knowledge has increased and is likely to change again before launch. To develop the site map we conducted a content audit of the site (to give you an idea of scale we stopped at 9 levels down and logged nearly 1000 pages!) We then took a digital red pen to the audit cutting out huge swathes of redundant content only leaving the good stuff behind. When we had reduced the audit down to something more manageable we then added sections for some additional site content for the site that we were aware of. This was then passed through an open card sort with prospective users of the site who were recruited against the personas and formed the basis of the site map.

You’ll see from the site map we produced that we went for a slightly different, non hierarchical approach to the map for a couple of reasons. The first was that we didn’t want to give the impression to the stakeholders in the organisation that one section was more important that another and the second was that because the content of the map is always changing it is easier to not bog ourselves down with details around where content should fit in the hierarchy at this stage.

User Journeys – The final stage of our UX sprint 0 was to develop typical user journeys for the new site based on the behaviours of the characters in our personas. We developed about 12 journeys and a typical journey looked like this:

“1. Book tickets to a screening

Nick has heard that Tron 3D has been released and loved the original, so has convinced his friends to go see it with him next Friday. He Googles to see if it’s on at the IMAX. One of his friend is a student and want a cheap ticket.

Main journey:

Google > BFI, What’s on > select 5 tickets for the best seats on the xx^th of Sept early evening (inc student ticket) > Pay > Get confirmation >

Further routes:

> Watch trailer/read (Sight & Sound) review/director interview (BFI live)

> If you like this, you may also like…

> subscribe to newsletter (upcoming films of same type?)

> become a member (emphasis on cheap tickets / how to save on tickets next time?)

> Explore the collection ‘Science in films as threat or danger’  (Special Collection) > Watch videos”

As with the site map we published these stories with a huge “This will change over time!” caveat but they were useful as a way of guiding the stakeholders and Product Owner when we started looking at the development roadmap. In order to develop the roadmap we prioritised the stories according to business goals, ease of development, and our knowledge of the organisation (the BFI has been through a massive restructuring during the lifetime of the project). The prioritised list of user journeys was then used to guide what went into the first sprint.

If you’re interested in reading more about using user journeys Jeff Patton has blogged about this.

So there you go. That was our Sprint 0. For seasoned UX professionals there’s nothing exactly earth shattering in there but from an Agile perspective it was definitely the right way to go about for this project and getting this stage of the project right helped the rest of the project no end. You’ll also notice that not one wireframe was produced during this phase!

In a future post I’ll write about how we work with Agile and UX in our sprints….watch this space!

Because I produced the templates for my own use I’ve not included any guides or a key with the templates. Below is a brief overview of the various elements:

• ID – User story unique identifier
• Wireframe No. – Area or wireframe page which user story refers to
• Priority – Business priority (just in case it falls off the wall!)
• Est. Size – Estimated size (durr!)
• PIctures on LH side – Pictures of personas. Replace the placeholders with the pictures you use for your personas and cross out the pictures which story is not relevant to. This will help the product owner when prioritising the backlog and also act as a reminder to the rest of the team.
• User story – Nick would like to _____ in order to ______ etc etc
• Boxes in bottom LH side – These statements refer to the Kano method which we use as part of user testing as a way of validating the various features. The reason why we include them on the story card is to help the product owner when prioritising the backlog. More on this here.
• Boxes on bottom RH side – These are our acceptance criteria for user stories. All of the stories must have been through a round of user testing, passed unit testing and also been signed off as acceptable by the Product Owner.

Feel free to download the original Omnigraffle file or the PDF and amend it to suit your needs. They’re double sided so if you have access to a duplex printer you can print two double sided templates per page of A4. If you have any feedback or suggestions please do let me know!

This months meetup is focusing on Agile User Research and I’ll be talking about the true definition of sprint zero from a UX perspective and the whys and wherefores of integrating user research into this stage of the project drawing from my experiences of working at the BFI.

Unfortunately the event is full and there is a lengthy waiting list already but I’ll be putting up my slides and notes here in due course.

One solution to this problem is to use the Kano Model of Customer Satisfaction which was developed by Professor Noriaki Kano in the 1980′s. In a nutshell Kano says that user preferences for functions or features can be distilled into 5 categories:

1) Attractive Quality – The ‘nice to haves’  or delighters, features and functions which add to the experience but are not essential and wouldn’t be missed if not included. For example the little bag of sweets that Firebox include in their parcels.

2) One Dimensional – features which (when they work and are done well)  add a great deal but cause frustration when they do not deliver as promised.

3) Must Be – The givens. These are the things we expect to be provided and while they do not add to the users satisfaction cause a great deal of frustration when missing or badly implemented.

4) Indifferent – Features which are neither good or bad and do not result in either satisfaction or dissatisfaction with users.

5 Reverse   – The best way to describe this is assuming that all your users are alike. For example a gadget which is so overloaded with features it is at the expense of the user who thinks your product is overly complicated.

Kano illustrates this best in this diagram:

Now using the Kano Model in user centred design is well known, in fact Andrew Harder who gave an excellent talk on Kano as part of his User Research as a generative partner with design talk at this years UX People which is what inspired me to look into this further.

We will be using a variation of the model to test users appetite for the features we are proposing as part of our usability testing sessions. We conduct one round of user testing towards the end of each sprint (I’ll talk about our approach to user testing in another post). At the end of the testing session we will ask users to rate the features of the wireframes  (a feature could be a page, a section or a widget) and use an aggregate of those ratings as a guide for when the Product Owner is prioritising User Stories (features) in the Project Backlog.

The rating we will use will look something like this:

How would you feel if feature x was to be in the new site?

• I’d really like it
• I’d expect it
• I might use it
• Its unlikely I’ll ever use it
• I really dislike it

These responses are then aggregated according to the persona (we recruit users for testing against personas, I’ll talk further about how we use personas in another post). So for example if we recruited 5 people who matched our Nick persona and 3 of them responded very positively to feature X then the corresponding user story in the backlog might read. “Nick really likes feature X and would like to see it included” or if we didn’t have a majority the story could read ” On the whole Nick really likes feature X and would like to see it in the new site”

So there you go. This model isn’t intended to replace the Product Owners backlog prioritisation function but should help act as a sanity check when looking at the user stories.