Last night, I was lucky enough to see Bill Scott (of Yahoo Design Pattern Library, YUI, OpenRico, Netflix fame) present at my local Ruby user group. He shared his thoughts about the successful design patterns that have defined today’s web. As someone who enjoys brilliantly designed “things” including web apps and sites, I found his talk very interesting.
Most (actually, all) of his talk was devoted to the consumer web. My head is almost always focused on how to take the good stuff coming from the consumer web back into the enterprise web. Bill’s ideas made me realize how little we (as enterprise web app developers) pay attention to the minute details that go into producing web apps that customers love. Bill is currently the Director of UI Engineering at Netflix. If you’re a Netflix customerfan, you’ll know that Netflix.com is a superb site. Netflix’ business depends entirely on the success of its site. Very small incremental changes could drastically affect their business. All of the changes they make to the site go through rigorous testing with real users and are carefully measured.
With the enterprise products I’ve been a part of building, we’ve spent some time on usability tests. However, they’re usually done before the product is even passed over to development. They’re usually done during the visual design phase. Once the UX teams have finalized their product designs, they’re approved and passed over to the developers to start building. However, most of the time, the product doesn’t end up matching what was designed by UX.
This process wasn’t always this way. I remember back in the PeopleSoft client-server days, most products didn’t go through any usability tests. I suppose the reasoning is that back then, most of the “ERP” apps were focused on back-end users who were trained to use the software so usability wasn’t that big of an issue. Today’s focus is in building apps that anyone can use without training. Aside from testing usability, I don’t know if we focus enough on learnability. In order for software to be easy enough for anyone to use, it needs to provide enough queues for users to be able to learn how to use it. Bill provides a lot of examples in his presentation above of how to do this.
The problem with the the visual design process in the enterprise today (as I see it) is that it doesn’t follow good software development practices like agile. Once a visual design is finalized, it’s passed on and never really iterated for improvements. Some enterprise software development cycles could take over a year or two from concept to design to build to release. Over that time, new UI patterns could have emerged as well as totally new ways to solve the same problem that the software originally sought out to solve. This is the reason why agile methodologies exists.
What Bill described as his overall process for building good looking web sites that work can be reduced down to an agile process for visual design. It doesn’t make sense to design once then move on. The process needs to be iterative. Feedback from real users with real data need to be used as a way of testing ideas and measuring success rates iteratively. I’m no expert with UX, but this process makes a lot of sense to me.
Anyone out there in Oracle UX land care to comment? Are you guys already doing this? If so, how’s it working?
BTW, Bill’s got a book coming out on this topic… added to my wishlist.
I REALLY wish that was recorded…
Good thoughts on how the waterfall method doesn't work for design or development. A response from an enterprise UX person:
I'm not a big fan of orthodox Agile methods, with the “code first, ask questions later” mentality. I think there is a benefit to spending some (small, controlled) amount of time up front to identify the tasks the user needs to perform and to translate those tasks using user-centered methods into at least a skeletal UI design.
However, I am a big fan of the general concept of iterative design and development. You are right: this is where Enterprise software typically falls down. But it's not just the UX process that needs to be iterative, the whole dev cycle needs to become much more iterative.
Typically, massive amounts of time are spent up front identifying requirements and doing design work, and the dev cycle gets pushed later and later. As we all know, iterative development and design gets critical pieces of the system working early in the cycle. These pieces of live code should be usability tested (using rapid testing methods for quick feedback cycles) and that information pumped into new designs for the next iterative development cycle. It doesn't have to slow down the process — it can be done quickly and can greatly enhance the end-product.
Unfortunately, that's not the model followed at most enterprise software companies. I think the lack of consumer-level polish in enterprise software is a result of many factors, and cannot be fixed by focusing on just the UI design process. The enterprise dev cycle is still mostly a waterfall model, with dev cycles that take years, rather than months. There's no way to rapidly iterate on a UI and keep up with consumer trends in an environment like that. Also, the typical enterprise toolset does not lend itself to rapid iteration.
Finally, to really achieve a stellar user experience, the company has to foster a culture of excellence in UI design. It has to come from the top down (see Apple). Too often, engineering or marketing concerns trump UI design, and the end-user suffers. Design and development should complement each other every step of the way.
So, that's my diatribe. We are totally on the same page about where enterprise apps need to go. And I think Oracle is making good progress towards bringing the best of the consumer Web to enterprise apps. What's needed to move them to the next level is not just changes to the UI design process, but a cultural change around the methods and tools used to develop enterprise software.
@dustin amen bro… we need to turn this place upside down and start building apps in an agile fashion.
well I'm certainly not going to defend ERP applications and their (our) usability track record. I will say, however, that we don't just do usability testing on prototypes, we also do it on the final product and attempt to adjust to what we find. Of course, not always, but at least we do try.
The problem, as I see it, was best described to me that “UE is fashion”. It changes regularly, most development of complex systems just can't keep up. Before we get it built it's out of date. The real answer is to have better architectural support for regularly changing (and updating) the UI without the cost of re-doing the application. This makes it easier to adjust to changes both from user feedback and from technology innovations. One of the whole points of a SOA is to isolate the business logic to allow for more rapid and frequent iterations of the presentation layer. Not somewhere we can get overnight but I think we really are trying to set ourselves up for better success in the future.
I like the minimal UI approach OOTB (think terminal), with the data surfaced in any number of standardized APIs produced in several languages with equivalent functionality (a la Fire Eagle). That way there's a working UI, but customers are encouraged to go nuts and build the UI they really want; embrace customization, let your app developers flourish.
That's just me though.
I like This !These pieces of live code should be usability tested (using rapid testing methods for quick feedback cycles) and that information pumped into new designs for the next iterative development cycle. It doesn’t have to slow down the process — it can be done quickly and can greatly enhance the end-product. Good Luck