The Key to Fixing Enterprise Software

In Jared Spool’s podcast on UIE.com titled “Time Traveling with Enterprise Applications – UX Immersion Podcast”, they explore the topic of fixing bloated, unusable enterprise software systems from a ux strategy perspective.

Jared Spool and company highlight how enterprise software is often database driven, e.g. “if it’s in the database, create a field for it on the screen”. It makes sense, since most of these systems were driven by engineering and built 10+ years ago. Back then, users and design weren’t as vaulted as they are today.

I enjoy how Spool and company flow from identifying the problem to fixing it. If there’s one golden nugget to take away, it’s the following tip: watch/understand the enterprise users suffering while attempting to complete tasks using the software; then start chiseling away, bit-by-bit, at the improvements – make sure each release has at least one of your fixes in it.

In my experience, it’s almost that simple – but not quite. People are often so preoccupied with pushing out features that even when they see user’s suffering to navigate the archaic interfaces, they don’t think “we better fix that”; rather, the thought process is “well, they’ll suffer one time to figure it out, but then they’ll know how to use it and won’t suffer any more since they’ll understand it after that first time.”

Other things holding back the required changes is the coaching/training departments that corporations invest heavily into. Each time a change is made, the training manuals and lesson plans must be altered.

And lastly, there’s the fact that if the software is so archaic, many great ux changes simply can’t be accomplished. For example, in the old of Microsoft-driven technologies (ASP), it was standard practice to always compute changes on the server and to push them to the front end. Whereas, great modern user experience accomplish these same tasks on the client side – allowing for state changes without a page refresh.

Conclusively, though Jared Spool’s plan of making incremental changes in each release is helpful, it falls short of describing how to accomplish great ux changes. In order to accomplish great ux changes in old enterprise software, there has to be a simultaneous build process – so for each feature that is carved into the archaic system, that feature is built out into the new system as well. At some point, the new will catch up with the old; at which point the old can be switched off (and buried!) and the new can light up the world.

The 5-Day Design Workshop … Sort Of

I recently had a startup ask me to brainstorm solutions to their current product. After a 1.5 hr session, they wanted to turn it into a 1-day project. But my reply was “no way – you can’t fix a product in 1 day”. Since then, I’ve been thinking more and more about what quantifies as Lean – and does it mean UXers should be able to create 1-day bite size projects?

My answer is still “no way”, however, there are steps we can take in a 1-week sprint that I find helpful. These are based on the theories of C. Todd Lombardo; and explained by Bruce McCarthy in his talk titled: Lean Roadmapping: Where Product Management & UX Meet.

Here are Lombardo’s steps toward a 1 week Design Sprint:
1) Interviews on Monday
2) Compare notes on Tuesday
3) Brainstorm what you want to prototype on Wednesday
4) Build the prototype on Thursday
5) Show it to Monday’s interviewees for feedback/validation on Friday

Of course, to hold interviews on Day 1, there has to be a considerable amount of planning on Pre-Day 1 in order to: get those interviews set up; UX and stakeholders assembled; and the re-visit on Friday with the Day 1 attendees. So, theoretically, a 5-Day Design Sprint works; but don’t expect to accomplish it in 5 days.