Yesterday Laurence talked about the challenges that a multitude of interfaces can present a solution builder, specifically in the context of ECM, and today Billy added his thoughts. While both posts seem to be focused more on visual interfaces (UI) than non-visual interfaces, the concerns raised apply to interfaces in general.
Here are my thoughts:
- I very much agree that it’s more a matter of should than can. Is the new UI or user experience relevant to my business? Does a new experience enable the retirement of any other experiences? Does a new experience lower training costs (e.g. is it more intuitive to my users)?
- At some level, all user experiences from a vendor should be consistent. However, one must also consider where ultimate experience control resides. For example, I see at least two major categories of users where ECM applications are concerned: (1) those who prefer a standalone experience, typically within their web browser of choice, and (2) those who prefer that the vendor provide an integrated experience within the primary applications serving the business’s knowledge work (e.g. Office applications, a third party portal, etc.).
- I agree with Laurence: UI should serve the task at hand; not the other way around. You have a job to accomplish and the provided experience should clarify and simplify that job–even anticipate next steps, etc.
- How a business is run and wants to be run will determine whether or not a solution has one or more graphical/visual aspects. Knowledge work is becoming more specialized; so, each user experience should be tailored specifically to the particular link in the value chain it serves. Some have called this approach “purpose-built applications” or “task-centric experiences.” At the same time, there are horizontal (cross-cutting) concerns with visual needs, too (e.g. CIO dashboards, BAM, management consoles for admins, etc.).
When you provide presentation tier code as part of your solution–“whole cloth UI’s” as Billy calls them, you should acknowledge that users can be a fickle bunch (read: today’s Lexus experience will become a Yugo eventually–it’s a matter of when, not if).
So you should have a well-factored architecture that separates business logic and services, which serve all your UI’s, from application logic and services, which serve a particular UI (e.g. web-based, Office-based, etc.). Doing so, should produce a “thin veneer” for a presentation layer, which is easier to evolve or replace. Again, the UI serves the task at hand; over time, a new UI may serve the task better.-Craig