As humans, we rely on language to collaborate on various projects, including the development of user interfaces for software systems. Wireflow is a language specifically designed to describe the high-level design of graphical user interfaces, particularly for mobile and web interfaces. Its importance is such that most developers refrain from coding until they have a full understanding of wireflow and until it is embraced by all stakeholders. But what exactly is wireflow?
Combining wireframe and flowchart, wireflows are used to document user interaction design for GUI applications. It uses flow, or a sequence of page transitions, to representing interactions, with each page transition captures both user interaction and system feedback, and each page represented by a wireframe.
Combining wireframe and flowchart elements, wireflows are used to document user interaction design for GUI applications. They utilize flow, or a sequence of page transitions, to represent interactions. Each page, called wireframe, captures both user interaction and system feedback.
The wireframe here is a visual language that can describe both the layout of the graphical user interface (GUI) components on the page and how users can interact with them. Each of these components has a distinct visual rendering as well as functionality: rendering the content, accepting user inputs, or triggering transition into a different page. By simply configuring these GUI components on the page, linking different pages according to interaction logic and data based on business goals, the resulting wireflow expose services, therefore bringing value to users. Wireframe/wireflow are very easy to follow, anyone with some GUI experience can easily understand and articulate it.
So why wireflow is important for building a graphical user interface?
- Wireflows are a great tool to get business owners to focus on what they want to achieve at high-level early in the design process and to get constructive feedback from them. This allows the product team to uncover hidden requirements early on so finalize the requirement faster, before starting on detailed design or implementation.
- Wireflow can save time and effort during the design phase too. Using wireflow to communicate with all stakeholders including design peers and the engineering team, we can try different ideas, and catch user experience error by getting our designs reviewed. This makes it easy to converge onto a design that is both useable and implementable.
- Wireflows can serve as a basis for detailed design and planning by different teams involved, thus allowing for the separation of labor. This can help to bring down the cost of building applications. Building GUI applications that greatly exceed the capacity of a single person or small team is also possible now as a blueprint can bring everyone involved on the same page easily.
The conversational user interface (CUI) applications, or chatbots, allow users to get what they want by just stating what they want, thus provide better user experiences for many use cases. But despite hypes around it, the good or even just usable chatbot is still few and far between. This is in stark contrast with their GUI application counterpart. Why? It is just too expensive and demanding to build a good chatbot today.
There are many factors to blame, for sure. But missing a wireframe/wireflow like high-level design language is an important one. Lack of effective way to communicate during requirement analysis, high-level design, relying instead on user stories, or even implementation to build consensus is really expensive, and that is the reason that chatbot is not more available.
So what do we missing? What does it take to have “wireflow” for conversational experience? It turns out there are only two issues that we need to address.
Missing conversational UI “vocabulary”.
The secret sauce for wireframe is its GUI “vocabulary”: a standard set of GUI components that can be customized both in visual and in behavior with respect to business data and logic. These components, including text field, drop-down menu, radio button, are distilled from years of practice. Each of these components captures an interaction pattern that everyone can follow. The pages that these components composed into, define how to collect user input and render a response graphically, allow the business to describe how they want to expose their service.
We do not have CUI “vocabulary”, or a standard set of CUI components that can model the conversational pattern and be customized for any business purpose. The only conceptual model available, the popular intent/slot model, is designed to facilitate the natural language understanding implementation. Although it captures what is needed from the user to access the service, it can not be used to succinctly describe the complex conversational experience at a high level. Thus it is not a good fit for an interaction design language.
Flow is not a solution.
For a graphical user interface, how users can interact with a site is predefined by its developers. User can only start from the home page of an app, and follow the rigid flow to access its service. This means you, as a designer, only need to define behavior on the happy paths, which can often be modeled by a tree of flows defined by wireflow, sometimes make sure that users’ input is legit at every step. Unfortunately, for conversational interaction, users can switch away from and come back into any state of conversation, as shown in the following conversation:
User: I like to get a ticket to ShangHai.
Bot: Which day do you want to leave?
User: What is the weather like there this week?
Bot: [display the weather for user]
User: How about Tuesday?
As you can imagine, attempting to define user experience by describing behavior on all possible flows can be futile, considering the combinatorial nature of how the conversation can transition back and forth. Trying to solve this through an end-to-end pipeline is also ill-conceived, as has been pointed out in “Do not build chatbot end to end”.
Dialog annotation on types, the “wireflow” for service chatbot
The goal of all user interactions is to create an instance of function types, enabling us to call that function and deliver value to users. It is evident that a function is a composite type since it consists of parameters, which can themselves be of composite type.
To create an object conversationally, we extract values from user input for each slot (similar to input parameters in a function), a process commonly known as slot filling. The filling of a composite slot can be naturally decomposed into filling each of its individual slots. Furthermore, the filling of a single primitive slot is divided into different states, with the conversational behavior of each state defined by dialog annotations.
By breaking down the definition of conversational behaviors into small components and declaratively attaching them to the type and its slot/state, a well designed runtime can conduct conversation to create the instance need to deliver the service user want, regardless of how the conversation has progressed. Since it only need to figure out how to fill the next slot based on the interaction logic defined in these annotations. For a detailed analysis, checkout interaction logic a type-based approach.
Parting words
Service chatbots allow users to access a set of services or functionalities via a conversational interface, each of such services is modeled by an skill. With a type-based approach, the conversational behavior to create instance are defined by the dialog annotation, which is attached to the types and their slots. These factorized annotations allows runtime to easily carry on a meaningful conversation for building the callable service objects, even when users’ arbitrary intent switching can result in an unseen conversation path. If you are interested in designing and building effective chatbots in a cost-effective way, OpenCUI is an implementation of type-based CUI platform.
Reference:
