It’s a fun history lesson around the Scott Guthrie bit.

The nuggets for non-devs is a bit hidden. First guesses/thoughts:

• Start with a picture/diagram, contrasting two things. (Once you find what that diagram is. Maybe WIMP vs (x)?)
• I’m of course immensely fond of the JJG Elements diagram to describe the missing links between funct spec + visual design: http://www.jjg.net/elements/pdf/elements.pdf o What you’re trying to communicate is that different deliverables account for different things. I have some comments about funct. spec as a signoff doc, vs containing the funct. spec layer + wireframes (can work) o What you’ve always been trying to say implicitly is that if you (well BAs) aren’t able to prescriptive describe a modern Web 2.x-ish web interaction model, then they should acknowledge this is a professional shortcoming. From there, you can discuss how they could better understand how to upskill or re-think their process.
• You’ll need an example of these interaction models. I don’t think they’re popping into people’s heads, particularly as there’s no ‘aha’ when you make your Visio/Axure point o What practical web application would you best borrow from? Facebook? Twitter? Onetime? Xero? o This is actually a point I’ll cover in my Webstock summary talk next week (Dev + UX group) with the Startup Alley winners – they both had strong cases as to why their approach was leagues better than the previous way of doing something

The other angle that I think will help is separating what you’re trying to achieve (the ‘problem’, write it out as brief bullet-points) from the ‘solution’. Currently, jumping to ask them to re-imagine their entire documentation process wins no fans. And it’s only proposing one solution – and you say we’re not creative!