Live Apps – Project process

A few weeks after I started working at TIBCO, with the Live Apps team, Sid, the product owner, told me that he was going on holiday and that while he was gone, he wanted me to take a look at possible enhancements for the main content view for each business process ‘app’. I discovered later that he had in mind some fairly superficial ‘surfacing’ of some of the data within the app resources, but what I came back with resulted in a dramatic overhaul and improvement of user understanding and product usability.

Initial problem discovery

This journey really began in my first week, when I performed a UX review of the product. One of the things I noticed was that I was struggling to understand my own business process ‘app’ as I had no overall ‘map’ of what it did. Instead I had the ‘app content view’, which really consists of a set of unconnected assets.

And the product displayed the states that each instance of the app passes through in a separate ‘states editor’.

Each ‘action’ available within these states had a separate view, similar to the diagram below, consisting of the various ‘tasks’ involved in each ‘action’. Many users saw this view and mistakenly believed it was the process map that they were looking for – causing further confusion.


The observation of this set of problems, particularly for new and less technical users, was validated repeatedly with user testing. Some even explicitly said they were looking for such a map or requested that we include one.

Exploring alternative ideas

I consulted domain experts about what such a map might look like. The answer was that I seemed to be describing a state flow diagram. The problem is that – even in a simple use case such as recruitment or sales order process – state flow diagrams tend to be extremely complex and hard to ‘read’. We wanted users to be able to see a clear direction or flow through their business process and not to be overwhelmed by connecting lines.

I ran a ‘design studio’ ideation workshop with my cross-functional team. We selected the best ideas and combined them, incorporating them into my approach.

Iterative design

I built a series of paper prototype designs for alternative ways of showing the ‘app process map’ in a way that was more user-friendly, iterating based on domain expert feedback, and then shifting to digital prototypes and testing with users and user proxies. Our map evolved to become a fully interactive diagram with alternating states and their associated actions that lead to other states. Connectors can be drawn directly and new states and actions dragged from a palette.

I realised that we could hide a great deal of complexity and emphasise a more linear primary path through the business process by making a distinction between elements that are part of the phase-based ‘primary flow’ and actions outside the main flow, which could be available from many states. In our new design these ‘ad hoc actions’, such as a ‘Cancel’ action, are not part of the primary flow, or any phases and by default their connecting lines are hidden. This substantially cleaned up the process diagram and gave users a much clearer, simpler picture of their process.


Due to the complexity of these changes and some backwards-compatibility issues it might create, Sid and I ran a series of dedicated stakeholder review sessions until the redesign was approved. “App V2.0” as it became known, now represents the main product roadmap for Live Apps.

Redesigning the onboarding process

When I arrived, the onboarding material and UI used inconsistent terminology and used it without defining it or clearly explaining how the various parts of the app worked together.

So, based on feedback from peers and users, I defined a simple mental model for app architecture:

  • app data
  • cases
  • states
  • actions

I worked to ensure this was used consistently across the UI. But it also involved overhauling the existing onboarding process.

Giving users the right information at the right time

Instead of a six and a half minute video, showing excessive detail of features that users hadn’t even seen yet, I worked with the Docs teams to produce a much shorter video that simply explained the mental model. This was followed by a guided wizard for creating the user’s first app, and a short tour of the application UI. Help videos for various features were relocated within those features, so that users were getting the right information at the right time. Animation was used to show users ‘where the videos went’ when they dismissed them so that they could relocate them.

Back to portfolio ยป