 |
|
 |
|
One For All: Back-end App Integration Alone Won't Solve User Interface Challenges by ASPs
By Joy Busse, CEO & President - Busse Design USA
Reprinted from A-Com Magazine, April 2001
At the February Application Service Provider Channel Conference, or ASPCC, in San Francisco, I heard quite a bit of good information about channel partnering, technology infrastructure and ASP business model strategy. It was a prestigious crowd with veteran presenters such as Microsoft.NET (www.microsoft.com/net) and IBM Corp. (www.ibm.com) and relative newcomers like Jamcracker Inc. (www.jamcracker.com). However, no one at this conference, or at ASPWorld or ASPCON, is talking enough about the user-centric experience and what all these services mean to the end user.
|
|
|
|
Well, I'm here to tell you we've got a huge conundrum on our hands. In the ASP model, we have heterogeneous applications uniting to present a supposed value-intensive suite of services and products to customers. However, independent software vendors (ISVs) are not thinking compatibility with other ISVs; they need more of an "open-source" mentality when it comes to how their products' user interface (UI) can mesh or chameleon-ize with other products that will be offered within an ASP.
Currently, users are experiencing multiple products with multiple interfaces when they use ASPs. Each application has its own learning curve and offers little continuity with the others. The lack of continuity for the user experience is a fundamental sin of UI user-centered design principles, and most likely will cause users to search for a more cohesive experience elsewhere. While there isn't an easy solution yet to overcoming this fatal front-end problem (because many of the apps, such as Siebel Systems Inc.'s ( www.siebel.com ) Call Center, are very inflexible with their current products' UI), there are some best practices that can mitigate the pain when in the early stages of user interface application product design.
ISVs need to adopt an information architecture schema that allows for maximum flexibility and modularity. The idea of creating multiple "what if" scenarios for the variety of ways an application will be joined in an ASP offering is key. The elements for consideration are cobranding, architecture and design, private labeling, page layout flexibility to move features/conventions around on a page, the ability to pick and choose certain feature sets (modularity--think portal customization and personal preferences)--to name a few. The "what if" scenarios should also include a human factors analysis--determining the different user models or personas and how their needs will differ.
As one speaker mentioned at ASPCC, ASPs are service providers and mustn't turn into professional services firms. That means you can't customize all these product and service offerings because it's not cost-effective. Yet, you can create a library of UI templates and style guides to help your prospective clients easily change your application UI to accommodate the "umbrella" UI strategy for a suite of products offered within an ASP, given that the right set of product parameters is established up front.
You may be asking, "Who owns or creates the umbrella strategy?" The answer: a "vision architect." The vision architect is the user-advocate and product visionary that has his/her finger on the pulse of what this service offering will provide the end user within the ASP. Ideally, this vision is created by myriad cross-disciplines coming together, such as marketing, product marketing and engineering. Engineers, as lone product visionaries, may have contributed to the lack-of-continuity syndrome. After all, more typically than not, product marketing folks and information architects are the front end, user-advocates, while conversely, engineers are looking at things from the back end--a very different point of view. When engineers look primarily at the back end, they inherently overlook the difficulties this conundrum presents to the users at the front end. Someone has got to own that user experience, and create a product that has all the wizardry the engineers create, but also the continuity between products, the flexibility to adapt the product, and the intuitiveness that users have come to demand. In an ASP model, this becomes even more crucial because of all the disparate parts and how they can affect the end user.
Suffice it to say, as this gestational ASP industry evolves, more folks will be advocating user-centric practices in application design continuity, as we see more and more end users complaining about the ASP experience. Try a little preventive UI continuity medicine, and surely your product will have legs to sustain the ASP revolution when it comes.
|
|
|
|
|
