Image © Hugh McLeod – www.gapingvoid.com 2007.
I’m posting this in a (fairly short) lunch break, so it may not be as eloquent as it should be…
I read my friend, Susan’s take on the current “enterprise software should be sexy” heat that’s running today. Started by Scoble, who quite reasonably asked:
Any of you have any ideas on how to make business software sexy?
A number of the Enterprise Irregulars and others have weighed into the debate, including Nick Carr (whose position I rather like, even if I don’t necessarily completely agree with his argument), Michael Krigsman in two posts (1, 2), Dave Snowden (who has some great things to say), Dennis Howlett (who I think is fence sitting a little) and Vinnie Mirchandani.
Personally, my take is that enterprise applications should be all of:
- functional – that is, they should do the job they were built to do
- reliable – that is, they should do the job well, and consistently
- sexy – that is, visually pleasing, usable and user-centric, “2.0″ or whatever you want to call it
The third point above, to my mind, is one of the great failings of enterprise software. I have worked on several client sites where major enterprise tools such as Lotus Notes, SAP and Siebel (and others, but these are the biggies) have been implemented to deal with significant and valuable parts of business. To an instance, not one of those presented a great (or even good) user experience. Instead, users were faced with:
- confusing, cluttered interfaces with too much content on a page or view
- task and process flows that represented business views of how the work was done rather than how the users actually did the work
- layouts where users were forced to jump erratically between elements and even applications in order to get a task done
- flows where it was actually not possible to complete a task due to bad design
- information architectures that failed to recognise either the business or the users and instead imposed some arbitrary “out of the box” set of navigation or flow rules
Frankly, none of this is necessary. Instead, enterprise applications should have:
- simple, user-focussed interfaces
- process flows that represent the way users need to work while also fulfulling business needs on the back end
- layouts that have straightforward process flows that lead to task completion
- flows that actually complete tasks in a single run
- IA that matches user and business needs
On top of those considerations, enterprise tools should also:
- facilitate and broker interconnectedness between users
- make it easy for users to share knowledge and information about the application and the data held in it
- ensure that users can connect inside and outside the wall with those whose data is being used
Putting my IA hat on, if information architecture and user experience experts had been, or were allowed to be involved at an early stage in the projects, chances are the user experience could have been “sexy”. Robert could have a better answer to his question and the current snarkfest wouldn’t even be a consideration. Instead, we’d all we working together hammering our project offices and senior management with all the good reasons that exist to have a strategic, user centered approach to software design right from the get go (which is what I argued in my presentation at OzIA this year).
Over to you. I’d love to hear your thoughts.
{ 5 trackbacks }
{ 18 comments… read them below or add one }
Yes, yes, yes. But how, how, how? And when, when, when? Without any real technical or design knowledge, I’ve actually been yammering on about this on my blog for a while now. If you think about it, some of the realistic obstacles to simplifying the “user experience” we all crave is what has stymied adoption for enterprise 2.0 too. These monolithic systems are complex and difficult to futz with for a variety of reasons. Layer over that the hierarchical, top-down, semi-paranoid state IT must live in faced with SOX, security, privacy, threat of being outsourced, etc., and the cultural issues magnify the inertia. Why would enterprise vendors be motivated to introduce radical design changes?
@Susan, my take is that the when is now and the how is by taking on a truly user-centered approach to the delivery of their applications. Given the delivery platform is now by and large, the browser, there’s no reason why the experience can’t be incredibly user-centered and meet the expectations of users based on their daily use of Web 2.0 applications in their personal lives (and, if they are lucky, their work lives as well).
I’m currently working on a project where the user experience is being treated strategically. A couple of my colleagues are doing similar work. Surprisingly, this is in government and not big business. What has happened is that user experience and information architecture people (like me) have been brought on at the start of the project rather than later on. Our work with end users of the final product (several releases over the two year timeframe) is heavily informing enterprise architecture, business analysis, project management, management decision-making and software and development decisions.
That said, I’m not deluded – I’m certain that several compromises will need to be made in terms of user experience as the project progresses. However, having user focussed decisions and staying centered on and in touch with end users is making a hell of a difference to the progress and acceptance of the project.
There’s absolutely no reason why this approach can’t be the one taken in any major enterprise implementation. Trouble is, it rarely is the approach and user experience is paid lip service at best in deference to a wholly business-centric view of the implementation. Which is IMNSHO the wrong approach.
Spot on, unfortunately there are so many reasons why this is not done.
Your post can be summed up by one of my most favourite gapingvoid cartoons has the statement “it’s not what the software does. it’s what the user does”.
@Michael, there are many reasons why enterprise implementations don’t consider users, I agree. But I don’t agree with the argument (and I don’t think you’re making it) that this needs to or should be the case.
It should absolutely be the case that end users and their way of doing their work should be a primary consideration in any software development exercise. People with skills in understanding and enunciating the desired user experience and the way people interact with systems should be an integral, early and strategic component of any development exercise. On top of that, the vendors should be getting the same sorts of people on board to help them make their tools more usable and friendly out of the box.
If this was the approach, I believe that many of these implementations would be cheaper and have more active and committed user acceptance.
Hi there Stephen.
Sexy huh? Social software is cheesy sexy (like my Facebook Fridge post) not sophisticated sexy. Just look at Facebook profiles. People like cluttered crappy and ugly cheese.
Baekdal wrote about the “Three Pillars of Usability”L – which is:
1. Get the job done
2. Make it efficient
3. Make it personal
so perhaps people prefer personal design to “sexy design” these days, as much as I prefer it to be both..
Nope I don’t agree with the argument either, nor would I ever disagree with you :p.
Unfortunately I see two reasons for this failure around usability. Firstly developers/engineers with no experience in UI are left to build a product/feature in isolation. Or secondly a like of understanding within the project team of exactly how the user completes the process. When you add both of the reasons together you get major failures.
@Jasmin “sexy” is just riffing off Scoble and the crapstorm he sparked. To my mind, all software, enterprise or not, ought to be designed with the user in mind, regardless of what’s happening under the hood to get the business done.
User centered development and design are far too often left out in the cold.
@Michael sounds to me like you’ve seen a lot of waterfall style projects where the user isn’t at the center of the development and design process. Take a look at my friend, Matthew’s presentation from the ABAA Canberra function last week – http://magia3e.wordpress.com/2007/12/05/user-centred-design-and-prototyping/ and http://www.slideshare.net/magia3e/usercentred-design-and-prototyping/ for the slides if his embed isn’t working.
I think the problem is that large enterprise systems are built to be incredibly modular with many optional components where the client configures and assembles the system based on their particular needs. This strong modular functional design will show through regardless of how well you try and design an interface that is flexible enough to cover up the seams unless another approach to assembling an implementation of an enterprise system is sought … and I don’t know how else that can be done?
Perhaps the systems should be interfaceless – and a UI custom built on top of the backend system modules once assembled? Like building a brick wall and then rendering it?
@NathanaelB just because enterprise software is modular and plug-together and its interface design and functionality has to now been “not sexy” doesn’t mean this state of affairs shouldn’t change.
I’m aware of at least one major Australian bank that writes completely custom interfaces for it’s Siebel apps every time they do a release cycle. That’s not to say what they build is perfect or even 7/10 on a notional sexy scale, but it does indicate that it’s possible to rethink enterprise software interfaces with some user centered decision making in the process.
Can the software developers be expected to do any sort of UCD in their UI if all they’re delivering to clients is building blocks?
Then again should the client be expected to invest time and money in completely developing an interface for those building blocks?
It’s a tricky one – but I think yes the developers could do more to make any template interface for each component more user-friendly generically and make the task of developing the interface at the client-side easier and reduce the technical knowledge overhead so the client doesn’t need to employ say LotusScript developers to code interfaces.
OK I doubt it’s possible to simply have a drag and drop Facebook-style interface designer as that’s too simplistic … but an easy way of designing an interface and mapping it to the backend modules and functions … with sensible default layouts.
@NathanaelB to answer your questions, in order:
1. Software developers, that is to say coders, shouldn’t be doing the UI. The UI should be functionally specified by a user experience and IA person or team. The software developers should simply be implementing a UI designed by user interface/IA experts in consultation with end users. As someone who’s done many years as a developer, I can attest to the fact that software developers aren’t generally good interface designers. It was only once I began the move towards the work I do now that I realised just what a bad job I had been doing on interfaces.
Developers tend to design interfaces to manage data rather than interaction. While this is understandable given that developers want to manage getting data in and out of an application, it’s rarely an optimal solution for end users.
2. The client/system owner should absolutely be expected to implement a user centered UI if out of the box components aren’t suitable. And, by suitable, I mean all of functional, reliable and user-centered.
The “out of the box will do us” approach is something I’ve seen in dreadful implementations many, many times. As I’m certain, have you.
On top of this, the vendors – the SAPs, Siebels, Lotuses, Microsofts and the like of this world should be engaging with users from the beginning in redevelopments of their software platforms, in order to have users considered early and often. Additionally, they should be connecting with their developer and user communities and evangelising this approach as a way to save time, effort and money. Take a look at Matthew’s presentation linked above for a good approach to this.
The reason, for example, that Office 2007 is so different to any earlier version is that user consultations and interaction were at the heart of the redevelopment process. Sure, Office 2007 throws users to begin with given the unfamiliar interface, but frequent users become significantly more productive with ongoing use.
Absolutely the developers shouldn’t be doing design; sorry, when I said “software developers” I meant vendors – as in companies, not individual programmers
Yeah..developers and designers have two different mindset. doing both task at the same time looks a little bit like a conflict of interest. if small system, maybe fine. but if in an enterprise or Fortune 500 company, trouble will come. if not now, it will be later…
I will pass on sexy for “personable.” I want my software to help engage me in my work and let me know that I am the center of her universe.
agree – but what is your definition of “user”? see my post this morning
http://dealarchitect.typepad.com/deal_architect/2007/12/ui-again-dont-p.html
if we can rethink UI and business process from the outside in – customer, supplier etc, I am all for it and ok with Ajaxing, web 2.0 it. But in turn I want UI for internal non-value added users turne off, destroyed…
unfortunately internal users have more clout than external users like you…they can put more internal pressure on the CIO. Software salespeople walk their halls etc. so their cries for prettier UI get heard when frankly they should not be in the business process at all, at least not for data entry
@Vinnie (crossposted from his blog)
In making enterprise apps more user centered, what I’m talking about is implementing a long, scientifically based, user centered process taking in elements of UI design, business process analysis, business precess reengineering and cultural change, all backed by strong HCI principles and human and organisational psychology. Using this process is something I discovered working with my colleague Matthew Hodgson (http://magia3e.wordpress.com). Before that, I was pretty succcessful doing the same thing, but much of my work was intuitive rather than scientific.
Taking a science-backed approach to user centered design on any application, let alone enterprise applications should lead to a better outcome for business and the users – internal and external. Design work and user consultation takes place across the entire development lifecycle, surprises are reduced in user land, decisions about interfaces can be made early and changed early (and cheaply) if need be.
Enterprise apps don’t need to be “2.0″, but given a significant proportion of users are now used to using applications that interact with them in that style (if there is a 2.0 style), we should be making the effort to adopt the best of what they are experiencing and put it into enterprise applications.
Everything you said is right. And I guess that user-centered should be the most important criterion for the great collaboration software. Let’s face it enterprise software is still used by the software guys mostly. We should make it simple – this is the basis. So that everybody could use it. And I would propose making it foolproof. So people wouldn’t be afraid to make mistakes and learn. We can observe some significant steps in this direction from Wrike’s side. It’s one of the hottest project management products right now http://www.wrike.com/. The guys are doing a pretty good job, utilizing the ways that most people are used to. I mean tools like email.