We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

What tools does every business UI need?

Vote 0 Votes
User interface (UI) keeps coming up as essential to user buy-in.  So what tool or component does every user interface need to achieve that?

9 Replies

| Add a Reply
  • User experience (both of consumer and enterprise software) needs to be simple and intuitive. Consumer and the latest cloud startups has led the way. Enterprise UI have quite some catchup to do. And many BPM products are too tech driven resulting in very poor user experience. It's time to bring the cloud startup and consumer approach to BPM. Not sure if that qualifies as 'tool', but that is in my opinion the most important aspect of BPM and user experience.

  • The problem with UI's is that they often complicate things by attempting to be too simple. Masking a complex step or series of steps relieves the user of the tedious systematic process, but that single button or click can be disorienting or even terrifying. In contrast to using, say, Google, where the process is simple, enterprise apps can dispatch transactions that have actual ramifications.

    The emergence of e-Business and web-oriented applications surfaced an appreciation for user “experience” and “engagement,” very different from the engineering and “human factors” approach of user interface design of enterprise systems. What is lacking in the overall discourse about it is how can people make use of the tools effectively, regardless of the technology. For example, what exactly is needed for people to not only be informed by these systems, through their own efforts but to use the insight to make well-informed and actionable decisions? Most people who are not technologists are unimpressed with features; they are interested in finding ways be more effective. It isn’t automatic..

    Unfortunately, much of what passes for ease of use on the user has not addressed a fundamental change in the operation of business. It’s been focused on simplifying things that aren’t simple, masking complexity and providing a pleasing interface (at best) to the individual using the system.

    Designing a UI for a broad swath of humanity is a challenge, but many B2C and B2B have done an excellent (though some are really dreadful). The key should be focusing on the actual work that will be conducted and mixing the right elements of engagement and seriousness.


  • Great, but difficult question! I think increasingly, the "business feed" is becoming important, which like your "social feed" shows you a fluid view of events of relevance across the company. It helps pull employees away from email, which is the default online home.

    Pankaj
    http://www.hyperoffice.com

  • @Neil, I think you make very good points on how many are trying to adapt 'modern UI' concepts -- particularly those adapted from today's smartphones -- to existing applications.

    The core problem with application UI today is not really visual design (don't get me wrong, that's often still a problem).

    Enterprise application developers have held themselves hostage by the history of the application and compounded their (and our) pain by adding every corner-case on the planet.

    What would be healthier would be to holistically review what the job to be completed by the application is today and redesign around the new business processes/flows.

    Many people are concerned about the re-training costs, but if you build an application that is intuitive and maps to the workers' job as it is today, a new UI...especially one that might have intelligence about task context (what do I have to do now, what comes next)...will have negligible training costs. Research has shown again and again that really good UX reduces training & support costs, improves productivity and customer/function adoption.

    OK, this is officially too long, but here are a couple of old posts you guys might enjoy http://www.softwareindustryinsights.com/2009/08/usability-is-underappreciated/ and http://www.softwareindustryinsights.com/2009/09/business-impact-of-usability/

  • Neither a tool nor a component, but rather a designer with a strong sense of user experience. I've found that UX is less about a specific skill set (although certainly folks with strong skills in that area are great if you can find them), and more about the simple ability to empathize with the end user.

    We've all made it easy to design UIs. Some solutions have built-in form builders; Process Director uses Microsoft Word; etc. But easy to build isn't enough: we have to have a clear idea of what we're building, and why. In that sense, eForms are sort of like Lego projects. It's really, really easy to stick a bunch of Legos together; it's a lot harder to form them into a convincing replica of the Millennium Falcon.

  • Great UIs are not just about being pretty. They reflect an underlying business process, and user-level workflow that has been well thought out, not just cobbled together.

    To answer the original question, the component every UI needs is 80% of the screen devoted to the primary focus the user's attention at that moment. In a call center it is relevant information about the customer. In a step in a business process it is the information required to aid accurate data entry or decisions.

    To Neil's point that there are probably serious ramifications to hitting the "GO" button in enterprise apps, a well design application addresses that. In the best apps the user has been led through a series of steps prior to "GO", collecting and cross-checking all required information along the way. The aim being to make the final action more a confirmation of the user's intent than a "finger on the button" moment of terror.

  • Although I don't buy the "simplicity at any cost" message, I think that one essential point in making system usable is to make them:
    - simple
    - to the point with respect to the business need and the user goals
    - tailored to the target users
    - uniform and coherent throughout the entire user experience.
    How to obtain this?
    I don't think it's a matter of which tools, technology, component or widget to use.
    It's more a design attitude and problem.
    UI design is a discipline per se, and should not be regarded as pure graphic design and aesthetics.
    There is an orthogonal aspect that is user interaction flow design that is crucial:
    - it is not business process design
    - it is not graphical editing
    - it is not technology selection.
    It's a specific design line that decides what should be the steps of the user interaction when accomplishing a goal. You may see it as a "process design in the small", only applicable to human-computer interaction.
    This aspect has been often neglected by system vendors and customers, thus resulting in awful and unproductive UIs.
    I foresee a big leap in this now, since OMG (the Object Management Group, the body that standardizes BPMN, UML and so on) has now adopted a new standard exactly going in that direction.
    The new standard is called IFML (Interaction Flow Modeling Language).
    IFML is designed for expressing the content, user interaction and control behaviour of the front-end of applications.

  • User Interaction has in my book little to do with GUI Graphical User Interface design. User interation happens on several layers that have to be designed in a hierarchical manner. Mobile touch screens have for example very different UI for exactly the same applciation. they are even different for a phone and a tablet due to available screen space. It is much easier to create an inutitive Ui for a smaller devive than for a larger screen because there is simply less information to digest and less options to do something.

    We have struggled for years to create a Ui frontend that does not require coding fpr flexibility for many different UC and UI requirements. The main problem is however that produts and applications are chosen mostly by users who wantt to see what they are used to one way or the other.

    In enterprise applications where people are mostly performing high transactions rates, not the intuitiveness but the reduction of all unnecessary steps becomes key. That is for example driven by the need of the application to change focus automatically in the 'workflow' of the user role. That may be very different for the same applciation but different users. People do not want to click the mouse unnecessarily to change focus hundreds of times a day.

    The most common way to descrbe user interactions are 'user stories' and 'use cases' and both fail dramatically to describe such detail, as neither does IFML. As it happens it would be wrong to describe such detail as users have no idea what they want until they see it either right or wrong. So you need a UI to start with to get to the UI needed.

    A key issue for todays multi-channel and multi-device environemnts is that the application has to be disconnected from the UI. A set of API calls (REST or SOAP) has to encapsulate the applciation functions so that the UI can be created around user needs.

    The UI has to specify what information the user needs to see to perform which optional actions. What we are doing is to enable the users to define their user stories explicitly and map them into a use case, where each on is ideally an encapsulated graphical TAB in the user interaction. The user story must be completable without swichting tabs or needing to know a hidden sequence of actions.

    I believe that the only way to improve on that is to provide an explicit ONTOLOGY of business terms that can be used to describe the user stories and use cases. These can then be mapped to UI components that match the user needs for low-level interaction (display styles and focus settings). But the main problem is that users will still find it hard to say what they need without actually seeing sample screens and sample interactions. So it is chicken or egg problem that most probably won't be solved.

  • I would say 2 tools one for the "design" then the tool that makes it easy to use? A couple of principles on the “use” tool. New information should only have to be entered once on to any form and be available for use as required anywhere including that form so intelligent grids make sense? The other core that is emerging from ACM is that the form is dynamically created for the authorised user with all required data and fields for new data for that specific instance of the task being undertaken. Now how you do that is another question….but I would suggest is a must have for BPM supporting applications?

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT