Enterprise apps *can* and *should* be sexy | acidlabs Studios
post-template-default,single,single-post,postid-714,single-format-standard,ajax_fade,page_not_loaded,,qode_grid_1300,footer_responsive_adv,qode-theme-ver-11.0,qode-theme-bridge,wpb-js-composer js-comp-ver-5.4.2,vc_responsive

Enterprise apps *can* and *should* be sexy

Enterprise apps *can* and *should* be sexy

It's not what the software does. It's what the user does.
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.

Stephen Collins
No Comments
  • Susan Scrupski
    Posted at 11:51h, 10 December Reply

    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?

  • Software sucks…a lot of the time : AccMan
    Posted at 11:57h, 10 December Reply

    […] conversation moved to the Twitterstream with folks like Luis Suarez, Stephan from AcidLabs and Ed Yourdon picking up the beat, claiming that the next generation of users will drive change. […]

  • Stephen Collins
    Posted at 12:08h, 10 December Reply

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

  • Michael Specht
    Posted at 12:37h, 10 December Reply

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

  • Stephen Collins
    Posted at 12:44h, 10 December Reply

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

  • Jasmin Tragas
    Posted at 14:12h, 10 December Reply

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

  • Michael Specht
    Posted at 14:19h, 10 December Reply

    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.

  • Stephen Collins
    Posted at 14:35h, 10 December Reply

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

  • Stephen Collins
    Posted at 14:38h, 10 December Reply

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

  • NathanaelB
    Posted at 16:58h, 10 December Reply

    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?

  • Stephen Collins
    Posted at 18:53h, 10 December Reply

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

  • NathanaelB
    Posted at 19:55h, 10 December Reply

    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.

  • Stephen Collins
    Posted at 20:33h, 10 December Reply

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

  • NathanaelB
    Posted at 20:49h, 10 December Reply

    Absolutely the developers shouldn’t be doing design; sorry, when I said “software developers” I meant vendors – as in companies, not individual programmers 🙂

  • vrempire
    Posted at 01:50h, 11 December Reply

    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…

  • Doug Cornelius
    Posted at 02:29h, 11 December Reply

    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.

  • vinnie mirchandani
    Posted at 02:49h, 11 December Reply

    agree – but what is your definition of “user”? see my post this morning


    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

  • Stephen Collins
    Posted at 05:29h, 11 December Reply

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

  • frogpond » Wiki usability and Enterprise software sexyness
    Posted at 00:43h, 12 December Reply

    […] of “industrial-strength-software proponents” are entertaining in a way because we know better (this is dire stuff, and I ask myself if those guys ever worked with enterprise-style-software like […]

  • Ulle
    Posted at 00:36h, 13 December Reply

    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.

  • Dogear-Nation - Episode 43 - Sexy Enterprise Apps » Dogear Nation
    Posted at 05:36h, 10 April Reply

    […] Tags: Enterprise apps should be sexy / Jasmin Tragas — http://www.acidlabs.org/2007/12/10/enterprise-apps-can-and-should-be-sexy/ […]

  • Doug Cornelius .com · Sexy Software
    Posted at 08:48h, 02 March Reply

    […] Stephen Collins of acidlabs thinks Enterprise apps *can* and *should* be sexy. […]

Post A Comment