It's not what the software does. It's what the user does.
Image © Hugh McLeod — www​.gap​ingvoid​.com 2007.

I’m post­ing this in a (fairly short) lunch break, so it may not be as elo­quent as it should be…

I read my friend, Susan’s take on the cur­rent “enter­prise soft­ware should be sexy” heat that’s run­ning today. Started by Scoble, who quite rea­son­ably asked:

Any of you have any ideas on how to make busi­ness soft­ware sexy?

A num­ber of the Enter­prise Irreg­u­lars and oth­ers have weighed into the debate, includ­ing Nick Carr (whose posi­tion I rather like, even if I don’t nec­es­sar­ily com­pletely agree with his argu­ment), Michael Krigs­man in two posts (1, 2), Dave Snow­den (who has some great things to say), Den­nis Howlett (who I think is fence sit­ting a lit­tle) and Vin­nie Mir­chan­dani.

Per­son­ally, my take is that enter­prise appli­ca­tions should be all of:

  • func­tional — that is, they should do the job they were built to do
  • reli­able — that is, they should do the job well, and consistently
  • sexy — that is, visu­ally pleas­ing, usable and user-​​centric, “2.0″ or what­ever you want to call it

The third point above, to my mind, is one of the great fail­ings of enter­prise soft­ware. I have worked on sev­eral client sites where major enter­prise tools such as Lotus Notes, SAP and Siebel (and oth­ers, but these are the big­gies) have been imple­mented to deal with sig­nif­i­cant and valu­able parts of busi­ness. To an instance, not one of those pre­sented a great (or even good) user expe­ri­ence. Instead, users were faced with:

  • con­fus­ing, clut­tered inter­faces with too much con­tent on a page or view
  • task and process flows that rep­re­sented busi­ness views of how the work was done rather than how the users actu­ally did the work
  • lay­outs where users were forced to jump errat­i­cally between ele­ments and even appli­ca­tions in order to get a task done
  • flows where it was actu­ally not pos­si­ble to com­plete a task due to bad design
  • infor­ma­tion archi­tec­tures that failed to recog­nise either the busi­ness or the users and instead imposed some arbi­trary “out of the box” set of nav­i­ga­tion or flow rules

Frankly, none of this is nec­es­sary. Instead, enter­prise appli­ca­tions should have:

  • sim­ple, user-​​focussed interfaces
  • process flows that rep­re­sent the way users need to work while also ful­fulling busi­ness needs on the back end
  • lay­outs that have straight­for­ward process flows that lead to task completion
  • flows that actu­ally com­plete tasks in a sin­gle run
  • IA that matches user and busi­ness needs

On top of those con­sid­er­a­tions, enter­prise tools should also:

  • facil­i­tate and bro­ker inter­con­nect­ed­ness between users
  • make it easy for users to share knowl­edge and infor­ma­tion about the appli­ca­tion and the data held in it
  • ensure that users can con­nect inside and out­side the wall with those whose data is being used

Putting my IA hat on, if infor­ma­tion archi­tec­ture and user expe­ri­ence experts had been, or were allowed to be involved at an early stage in the projects, chances are the user expe­ri­ence could have been “sexy”. Robert could have a bet­ter answer to his ques­tion and the cur­rent snark­fest wouldn’t even be a con­sid­er­a­tion. Instead, we’d all we work­ing together ham­mer­ing our project offices and senior man­age­ment with all the good rea­sons that exist to have a strate­gic, user cen­tered approach to soft­ware design right from the get go (which is what I argued in my pre­sen­ta­tion at OzIA this year).

Over to you. I’d love to hear your thoughts.