Chat + Cards Navigation UI

Chat + Cards Navigation UI

Our latest experiment tries to combine the Chat UI with a Card Navigation UI.

Why combine the two?

Most Conversational UI approaches seeks to embed a full UI inline in a chat flow, but that's likely to fail, but there is still something about chat flow that works really well.

Simple decision flows fit well inside a series of interactive chat bubbles. Many business workflows are modelled in a wizard interface, and could equally be modelled as a sequence of interactive chat bubbles. As such it would fit more comfortably on a Smartphone than a wizard interface.

Other applications such a text or graphic editors would fit horribly in a chat. Information browsing such as jumping between product details pages would be hard to implement sensibly, but the search could originate in chat. our conclusion is therefore, a browsing and manipulation concept in addition to the conversation.

Conversation has an important role during the introduction to a new service as we onboard the user, during the transition from trial to paid customer, and when something unprecedented happens and the user needs advice. These are often handled by separate features.

Separate Chat Features

When the user is required to interact with a setting or workflow the common way is a notification and highlighting the path to the setting. Instead the notification can pop up in the chat with the setting or form that needs to be filled in.

End of Trial
Device Moved

Permanent Navigation Space

The Hamburger Menu is a dominating navigation paradigm in Smartphone apps and web layouts, often combined with tabs. The downside is that it tends to frame the content ruining the sense of providing a view into a bigger world. It also adds Permanent Navigation, subtracting from the available space. With touch devices swiping is another option for navigation. Additionally animating the UI elements during the swipe gives a great feedback and sense of manipulating in a real world.

Bottom Navigation

The default paradigm for web pages is already vertical scrolling between different parts. On mobile vertical swiping normally means scrolling. If you put all the elements of a real application in one sequence forming a document, it would be long. Too long to in and off itself to be usable for navigation. The content off screen needs to be more discoverable.

So how can a scrolled page be made usable;

  1. parallax
  2. peaking further content
  3. stacked cards
  4. priority ordering
  5. grouping

Some form of stacked cards view should work well with the sort of content we have in mind, so that is the starting point. The alternative is scrolled content parallax effects and stacking to tighten up the perceived length of the page.

Moving Between Chat & Cards

In this experiment horizontal swiping at the top level would switch between completely separate sites or domains. Say the current content reflects your conversation and cards related to your interaction with the shop you're currently visiting. If you swipe horizontally you go to another context for your home and family. Vertical swiping is then used for navigating between the cards that belong to the context and the conversations within it.


It might make sense to have the conversation in a card rather than a separate part of the UI. As a card the conversation can be moved down the stack at times when it has less priority. The downside would be scrolling inside a card, potentially a lot. So far we assume it would be a lesser choice.

Using the space in chat

Facebook Chatbot interface embeds the choices in the message received. This constrains the space horizontally, which may be needed for more rich response forms. The response form should be just above the keyboard(if shown), but still be tied to the question bubble prompting the response. This supports the notion that the bottom of the screen is for user reactions.

When the chat is just the user responding to the regular service, there is no real need for chat heads to inform who is talking. The distinction between left/right side is sufficient. Once individual service representatives respond the chat heads should appear to distinguish who is talking on the left.

Personal Messages

The Prototypes were designed with Sketch and Principle to try out the navigation feel, content is intentionally vague.