News

Last month, I spent many hours reading proposals for UX Australia 2011 – well over a hundred of them.

The eighty-or-so proposals that weren’t selected were submitted by good people, were most likely good ideas, and may have turned out to be fabulous talks. But they had some common attributes – some were too short, some were too high level, some were a bit jargon-filled and for some we couldn’t tell whether the proposer had any experience in the topic they were suggesting.

For a conference like ours, and others that ask for submissions, the presentation proposal is the sole chance to sell your idea and get a place on the program. It’s a single shot – with over 100 proposals and 24 spaces, we aren’t going to be chasing you and asking you to expand or clarify your good idea (we do give quite detailed guidance about expectations up front).

So for next time, here are some tips on making your proposal even better.

Write a ‘proposal’

Proposals and final descriptions of a presentation are quite different things, with very different roles.

The role of a proposal is to sell your idea to the conference committee. In a proposal, we want to hear exactly what you want to talk about. We want to know what techniques you’ll cover, what the lessons you learned were and what your ‘new method’ actually is. We want to make sure that your insights are new and interesting, not something that we all discover in our first couple of years working.

The role of a talk description is to encourage people to come to your talk. It can tease, hint and have open ideas. You don’t need to include all ‘answers’ or give away the punch line.

This year a lot of proposals were written as presentation descriptions. Inevitably they were too short and too high level for us to make a good assessment of what would be covered.

Be detailed & concrete

Some proposals this year just didn’t have enough detail. Reviewers looked at them, we looked at them, and we all said “there’s just not enough here to go on”.

The proposal has to be detailed enough for us to get a clear picture of what your idea is. We want to be able to see that it will fill 45 minutes and know what you’re likely to cover in that time.

They also need to be concrete. We don’t want to hear that you’ll describe the methods you used – we want to know what the methods were. We don’t want to know that you’ll describe the lessons you learned – we want to know what you learned.

Proposals don’t always need to be long to be detailed. Long proposals without detail are worse than short ones!

Be clear

A conference proposal is no different to any other written communication. It needs to be as clear as it possibly can be.

Remove jargon, use active voice, write in first person, use clear nouns and strong verbs.

Don’t set up strawmen

I’ve reviewed for a number of conferences and have often seen a strange type of proposal. It describes a situation – usually a behaviour that practitioners demonstrate, or a design issue – then explain why it’s wrong, and why their approach is right.

These never appeal to me. Firstly, the situation described usually doesn’t resonate with me, so it feels the proposal is trying to blow down an inaccurate premise. Secondly, they’re negative. Not a good start.

(this may be personal – I certainly see enough of this type to wonder if I’m the only person it bothers)

Explain why you’re able to cover the topic

This year a number of proposals had great ideas but we couldn’t figure out if the presenter had the experience in the topic. We checked the submission, the bio and even dug around on the web to find out whether it was likely they’d done the work or just had a good idea.

UX Australia may be a bit different to other conferences, but one of our key guiding principles is that presentations are ‘grounded in experience’. We know that the best presentations come from people who have done the thing they want to talk about, and not just once but a number of times. We know that the only way to teach others is to have properly experienced it yourself. It isn’t enough to understand the principles or have thought about it. You have to have done it.

Assuming you’ve done the work, tell us where, when and how often.

But I did all that…

Even if you did all this, sometimes a proposal may not be accepted. This can happen because:

• the topic wasn’t quite right for the audience
• it’s been covered (by you or someone else) too much already
• there were other proposals on the same topic

And our favourite example

Naturally, we did receive many great proposals.

The one that received highest review scores was interesting as it’s a fairly straightforward idea, and something that most of us probably already know about. The most interesting thing was that it was a great proposal. Clear, detailed, friendly, with some humour. It was from Jay Rogers, and is below:

Presenter: Jay Rogers, Design Manager, Atlassian

——————————————-

Mockupitis
Pronunciation: \ˈmäk-ˌəp-ˈī-təs\
Function: noun
Date: 2006

1 : The tendency of a UI mockup to make assumptions about design constraints based on poorly-chosen sample data used in the static wireframe, photoshop comp, or interactive prototype. Short labels that fit neatly into the space provided for them, evenly-dispersed text, small numbers of columns, orderly and strangely regular tabular data, convenient numbers of items in lists that happen to fit just precisely into the page, the list goes on. This tends to reduce the design to a limited visual exercise instead of exercising its ability to handle more realistic formations of user data.
——————————————–
Abstract:
The subject of prototyping has been very hot the last few years, as pressure increases to create compelling interactive products faster, cheaper, and with less risk. However, the discussion of new tools, services and processes is often preoccupied with form rather than content. This talk concerns itself with mockup content – and discusses how to evaluate the sample data included in a mockup to make sure that the design is actually going to work once it hits real life.

Do *your* mockups have mockupitis?

Discussion:
This talk is for anyone who designs interactive products that display content, especially user-generated, structured content, and will focus especially on web-based software. It’s meant to last about 35 minutes, with 3 main focus areas:

1) Definition and Examples – an introduction to mockupitis, and a set of sample mockups that exhibit various design problems because of the data chosen by the designer. We’ll ask the audience to help identify issues with the mockups.

2) Strategies – the middle and longest section of the talk breaks down mockupitis into a) errors in scale b) errors in time (sequence) c) errors in fidelity – we’ll look at exercises to test mockups for kinds of mistakes that crop up in these areas.

3) The last part is about Tools – we’ll share evaluations of the mockup tools currently on offer with particular interest in how they support variation of sample data.

I’ll be honest and upfront about some blunders made by myself and my teams, and in the 10-minute Q&A period I’d like the audience to share some war stories as well.

Stretch goal: I’ve been working on a scripted tool to switch out data in my HTML mockups. I’ve just registered mockupitis.com. I have 4 months to finish the tool and publish it to mockupitis.com to announce at UX Australia and make available to anyone who wants to take advantage of it. But, this is a stretch goal and is strictly icing.

Presentation Notes:
My favorite presentations at conferences are very canny about level of detail. They convey enough so that you can grasp the main point of the talk and remember it later, but they also provide you with plenty of tips to further reading and information on the topics should you choose to dive deeper. So I’m big on references and bibliography slides so that the attentive can get to material behind what we’re able to discuss in 45 minutes.

I’ve been discussing mockupitis with teams for 4 or 5 years now, and it continues to be a problem. It’s time to go public.