We have got IT covered

Which division do you need?

Blog Archive

Sep 10 (1)

Aug 10 (8)

Jul 10 (10)

Jun 10 (8)

May 10 (14)

Apr 10 (20)

Mar 10 (10)

Feb 10 (3)

Our Blog

Blog RSS

Paul Saunders, 14th July 2010

How to make Simpler MRO Software: Part 2

5 comments

This is the second part of a series of suggestions about what can be done to start making software for the aerospace MRO industry simpler. In my last post I suggested that MRO software vendors should open up their code to third party developers. Today I am looking at the importance of User Experience.

Part 2: Outside-In Design
Aerospace MRO is a complex industry – I’m not debating that. I mean it’s not rocket science or brain surgery, but I’m told by those in the MRO software industry that its really really really complex. “Complex Cubed.” So it should follow that the tools utilised in MRO are also complex and to try and make them simpler would be…. well it would be just too simplistic.

Designers and developers of MRO software tools have no end of insurmountable problems to overcome. They can’t possibly be expected to worry about the user’s problems before their own. Therefore they often don’t worry about that. They expose the inner complexity of their software to the user and boast about how mind-blowingly complex it is… After all complexity adds value.

Of course I don’t actually believe those previous statements, hopefully I am exposing just how daft I would sound if I did believe what I’ve been told.
If Google had been made by a significant majority of MRO software vendors instead of being posed with a text entry field and a go button, you’d be given a map of its servers and asked how you’d like to load balance the search you’re about to perform; whether you want to filter results, include adverts, search nationally or internationally, include foreign languages, whether you want to be included in the various control or experimental testing groups, etc etc etc…. but it doesn’t work like that and this partly explains Google’s success.
 
Google conducts a series of simultaneous calculations in only a fraction of a second 300 million times a day. But you as a user don’t see any of that, and you probably don’t even begin to understand how Google works.


 
You just want to type in your search criteria and find the page you’re looking for. It just works – you don’t even need to think about it. If only MRO software could be like that.

Google takes a fantastically complex process and renders it simple for the average user by designing the interface from the outside-in rather than from the inside-out. The IT industry and other technology industries are littered with countless examples of successful outside-in design where a simple and delightful user experience has proven to be the best way of working, but still we are stricken by an MRO software industry that is obsessed with designing applications and interfaces from the inside-out.

“You are not designing for you, but designing for your users.”

MRO software often has a really sophisticated user interface, but I don’t know any that provides an awesome user experience. Mainstream enterprise level software users are surrounded by software. They use social media, they download apps to their phones, they use software and applications at home, on their PCs, their consoles and on devices in their home or car… they know what software they like and will consume software in the same way that they consume media. They will return to a particular application time and time again and build brand loyalty based on user experience. Equally they know what they don’t like and if they don’t have the patience or ability to articulate what the problem is they will give up or go elsewhere. Vendors of enterprise level software should pay attention to this fact and improve the user experience of their products.

If your software is bland, difficult to use and frustrates rather than delights then this will have detrimental effects on the software’s success. When users like software, they will use it more efficiently and more effectively, increasing productivity thus promoting a better return on investment, etc etc etc…. leading to future sales of your software…. ultimately leading to safer, more compliant aircraft and so on….

I’m not going to drill down into the details and theory of user experience design… this stuff is well documented with empirical evidence everywhere. If you want to know exactly what shade of green a button needs to be to register an improvement on click rates then that stuff is out there. Here are just a couple of general issues to consider.

Invest in Usability
Changing a company from one that is hostile to usability to one where user-centric design is integrated to everything the company does is a major step. Changing from purely functional design to usability design and from quality testing to usability testing requires new skills, new ways of working and new personnel. As with values such as quality and compliance usability can only be integrated into a product if the company invests time and resources across the whole organisation. Incorporating user experience strategies into your business strategies is the way to put your product on a path towards simplicity. Make space, time and money available for usability improvement or else it simply won’t happen.

Human Factors
From comments I have seen on the various discussion groups, on blogs and from evidence I have experienced first-hand as a software selector, as a software user, as a software installer and most importantly as a software designer and vendor I believe that the human factors in aircraft MRO have been overlooked when it comes to improving MRO software. We ensure that we don’t create trip hazards by trailing network cables across hangar walkways. We ensure that engineers don’t get repetitive strain injuries or go blind from entering data all day long… but other than customising one or two screens, or fitting RFID tags to ground equipment what has been done to the actual MRO software to help make user’s jobs as efficient as possible? Where are the field studies, where are the usability tests, how much attention is paid to usability data?

MRO software isn’t focussed to the user’s requirements. MRO software isn’t ergonomic. MRO software is cumbersome. MRO software can be made simpler by examining the human factors involved in using the software and developing software from the outside-in.

MRO software vendors think they are already doing all they need to do by holding annual user forums and software advisory board meetings – but this is chaff. Who attends these meetings? CIOs, CFOs, Technical Directors? Sys admins at the very best. None of these people represent any serious amount of system utilisation or expertise in the nitty-gritty of the software. All these get-togethers serve to do is limit the development of software to “design by committee”…

Designing by Committee

Collaboration is great. Finding out the answer to a technical issue by talking to an expert is fine. But designing simple software by committee is nigh on impossible. Michael Arrington of TechCrunch, recently wrote:

There’s a saying I love: “a camel is a horse designed by committee.” A variation is “a Volvo is a Porsche designed by committee.” Some of the best product advice I’ve ever heard goes something like “damn what the users want, charge towards your dream.” All of these statements are, of course, saying the same thing. When there are too many cooks in the kitchen all you get is a mess. And when too many people have product input, you’ve got lots of features but no soul……

Product should be a dictatorship, not consensus-driven. There are casualties, hurt feelings, angry users. But all of those things are necessary if you’re going to create something unique. The iPhone is clearly a vision of a single core team, or maybe even one man. It happened to be a good dream, and that device now dominates mobile culture. But it’s extremely unlikely Apple would have ever built it if they conducted lots of focus groups and customer outreach first. No keyboard? Please.

Layout
Consider the layout of software elements and how they will be used. Most people will enter data into a screen from the top left to bottom right. Yet it amazes me that most software shifts the users attention back up to the top left again to save the data they have entered. Surely the control to advance should be in the bottom right? Right?

 
If there are several steps required to carry out a complex transaction then group them together into a logical order on the screen or menu. Even better, join them together in a wizard type interface. Users hate having to scout around modules looking for the next step in their process. Users shouldn’t have to think…. It should just work.

Microcopy Writing
In most MRO software I have seen the copy writing is atrocious. Most developers assume that copy writing only belongs in the marketing and sales content…. Well guess what? Users have to read the content of software so it really is something developers should think about. The interaction wording that surrounds the user interface of a software product is often known as “microcopy” and can add incredible value to the product, or at least bad microcopy can have a massively detrimental effect on software usability.

As with all elements of user experience theory the devil is in the detail. Feedback cycles that acknowledge and confirm software actions or problems whilst appearing to be trivial have a major impact on how users regard software. Put some effort in. Don’t just leave it to the developers to decide what an error message should say. They don’t think like users. They understand what “invalid text entry field” means… my Dad doesn’t and he might be your user.

Get your microcopy written by someone who didn’t drop English at school at the first available opportunity, preferably by someone with English as their native language. That isn’t a derogatory statement about your offshore development team – they’ll probably thank you for employing a copy writer. Would you get them to write the content of your sales brochure? So why get them to write content for your product?

Removing Stuff

One of the key principles in improving User Experience is to remove elements from an application. This can only practically be done at a design stage, because once a feature is in the wild, only the foolhardy would attempt to remove a field or a feature. There is one quote that I return to again and again as a mantra which comes from Antoine de Sainte-Expury the author of “The Little Prince”. The quote has nothing to do with software, but is unbelievably relevant to user experience.

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."
Without a change of culture, this suggestion is incredibly difficult…. In my next post on this subject I will focus on providing some assistance here by “Learning to say No”.

Related Posts:
How to make Simpler MRO Software: Part 1
Why MRO Software isn't Simpler
Why isn’t MRO Software Simpler?

Aleksandra, 15th July 2010 at 10:29pm

Hey, I know one MRO software that uses the button 'I'm Feeling Lucky' as well! Only we called it 'Save', just for fun...
;)

Aleksandra, 15th July 2010 at 10:41pm

and about the design... I could not agree more

when I first saw a MRO system, having worked for a few years with SAP R/3, I was truly astonished. Each form was different, it was not logical for me at all.
And guess what... after some time I gave up and stopped noticing it. I guess the people who write software are the same 'blind', they just got used to their own writing.

Maybe the software houses should rotate their staff more eagerly so that they can look at the interface with a fresh eye, if that's possible without employing new people all the time.

And about the native speakers for the text bits - I fully support this, as a non-native speaking writer who tried her best, yet some things are hard to change in the organisation chasing its tail all the time... I cannot even imagine a foreigner writing instructions for me in Polish, it would be like a GPS switched to the PL langugage... you can die of laughter, the language is so unnatural.

Paul Saunders, 15th July 2010 at 11:41pm

Aleksandra,
Thank you for your comment. You are right, introspection is a big problem for MRO software and for aerospace IT in general. I am planning to write about this in Part 4 of this series.
Paul

Aleksandra, 16th July 2010 at 7:34am

OK, i don't want to jump over subjects.

Another thing crossed my mind as I was reading it again. I remember the first most frustrating thing in the MRO software I have seen was the access to data, related to a record I was looking at.

E.g. we have a list of purchase orders... in SAP (which I consider a very good piece of the system, well delevoped and mature, not without failures of course) you could display the order from such a list (of course), but you could also reach the details of each element, like supplier details, part details, delivery address details... not by adding several separate buttons to a toolbar, but by double clicking on a desired element...

Then I got used to it too...

cheers!
AR

Paul Saunders, 16th July 2010 at 8:52am

All good points Aleksandra... thanks again for your passionate comments.
Three major principles in simplifying software are to Remove, Hide or Shrink features and elements... One way to achieve all those in one hit is to consolidate features into other elements... so if your data grid becomes filled with hyperlinks then you effectively can remove several menu items in one swoop.
Doing this too much can obfuscate the data you are trying to present. The master of Visual Display of information is Edward Tufte. Worth reading up on if you are remotely interested in this area.
Paul

This article has 5 comments

Bookmark this...

Linked In Twitter Digg Delicious StumbleUpon Reddit Facebook Propeller