UX Australia News

How to write a kick-ass conference proposal

27 May 2011

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


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.
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?

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.

(And Jay attached this file: mockupitis.pdf)

Leave a Reply


Mail (will not be published) (required)

6 Responses to “How to write a kick-ass conference proposal”

Destry Wion says:

This is great advice, Donna, as anyone who has reviewed conference proposals can attest. You hit all the types one often sees (too vague, too high-level, off topic, too negative…). I’d even add too self-serving.

While advice like this should be taken to heart by hopeful speakers, I think organizers still have another task beyond just evaluating the entries. How many times have we seen conference programs where the style, tone and length of session descriptions were all over the board? You could add speaker bios to this issue too, even more so.

Like anything else, a conference website needs a good content strategy, and editing (or *normalizing*, if you will) session descriptions and speaker bios with an emphasis on being consistent and concise, really makes a difference in how they read. Plus it’s an opportunity for organizers to shape and direct their conference messages to; not business messages, exactly, but topics for the given year, etc.

In any case, a great contribution for organizers and speakers everywhere, Donna. Thanks!

Btw, I wouldn’t have known who the author of this article was (there’s a lot of first-person usage) if I hadn’t followed your tweet here. https://twitter.com/maadonna/status/73994468637945856

That’s probably an issue for UXA site owners.

Donna Spencer says:

Thanks Destry for your comments.

I don’t agree with you about completely normalising the program. I think our style of conference is about assembling a great group of speakers into one place. They are individuals and have an individual approach to the way they describe their presentation (and to how they present it too). I read through each description and fix obvious grammar issues. Sometimes I’ll fix a sentence or two if I think it’s really obscure and I can figure out what they meant. But I’d never normalise them or change people’s bios.

The conference isn’t about the organisers – we don’t have a conference message. It’s about the speakers and attendees…

And I’ll fix the template tomorrow (I am the UXA site owner) – I must have lost the author name last time I fixed some stuff.

[…] Spenser wrote a great post on the UX Australia conference site about writing excellent conference proposals and how proposals are different from presentation descriptions. It’s a must-read if (like me) […]

Destry Wion says:

Hi Donna,

I realize you’re representing UXA here, but my comments aren’t specifically directed at your event. Just so that’s clear.

I agree 100% about a conference (UXA or any other) being about speakers and attendees, but that doesn’t mean organizers don’t have some responsibility to help create the best event they can. And that means right down to the conference website’s content, which plays a critical role leading up to the event, as potential attendees will be reading it and making decisions first and foremost about whether or not to attend.

So editing might mean more than fixing typos. It might, for example, mean whittling down one person’s bio from four paragraphs to two if most other bios are only one. E.g, removing excessive detail about one’s educational background, which really doesn’t mean a lot against just having the right experience. That’s what I meant by editing/normalizing, and I never said “completely normalizing”, whatever that means.

Of course any editing of submitted content should only be done if the speaker understands in advance that might happen, and that’s par for the course; at least for events I’ve worked on.

Also, it’s my experience that speakers, even experienced speakers, are very open to working with organizers to shape their presentation descriptions so they do fit the aims of the conference. That’s not self-interested organizing, that’s collaboration between two key roles in putting on a professional event.

I think conferences are a lot like movies, actually: organizers/directors, speakers/actors, and attendees/attendees. When the directors and actors are in sync and the storyline is stellar, the ticket buyers get block busters and walk away happy.

But like movie directors, organizers come with different approaches to doing things, I suppose.

At any rate, your article’s original points about writing proposals are (still) excellent, and that’s really the focal point here.

[…] How to write a kick-ass conference proposal « UX Australia […]