The Application is the Wizard
This is the first of a planned series of three articles on the design of Feesability.
We've spoken elsewhere about our view on the current processes involved in litigation costs budgeting and why we believe they have to change. It's in order to propel that change that we created Feesability. Feesability is more than an application that helps you to plan and compile litigation budgets – it's an application designed to establish new standards and promote new processes.
The task to design the interface of Feesability is intrinsically linked to an understanding of how these new standards and processes can be translated into a goal-oriented and user-friendly environment.
A B2B-application with a peer-to-peer logic
The first and in many ways most important decision in the design process was the choice of platform. We wanted an application with a small footprint and a low threshold, which is why we decided to build a web-based application as opposed to a desktop software product. In addition to facilitate sharing and collaboration, the web provides a scalable environment and easier implementation of updates – and you are not tied to a stationery, wired, device. When taking the decision on platform, every argument for a desktop solution was out-weighed by options available through current web-based technology.
We think the recent crop of web-based productivity applications and the new generation of smart devices have created a new awareness among professionals that translates into a certain expectation. We now expect and demand our tools to be as simple, easy-to-use and functional as any consumer product – and rightly so. Why should our office applications look like Windows 98, be full of illogical idiosyncrasies that force us to work in counter-intuitive ways and often make us refer to an instruction manual?
A mental modelOur basic premise when starting to conceptualise the application was that a new tool for litigation budgeting must aim to meet the expectations and demands mentioned above. It must be an application that feels easy, intuitive and pleasant to use. An application that doesn't need a thick instruction manual or 'wizard' to guide you through the set-up, but one that makes use of common and well-established interface patterns. Our mantra during the interface design stages soon became "the Application is the Wizard".
Crafting a tool
Our decision to build a web-based application had repercussions in the sense that the already existing prototype (1), while serving as a reference in terms of features and functionality, to a large degree had to be completely reconsidered.
In addition, our approach meant that the focus shifted from the processing of data to the experience of working with the data. "How" the user interacts with the application was regarded as having the same importance as "what" the user is inputting. We believe that's the way to think about a tool; if a tennis racket doesn't feel right in the hand, its strings are too loose, the shaft too short, or the balls bounce too low, you can still play a game of tennis but your experience of playing will suffer.
Good for catching balls, not so good for hitting ballsWire-framing processes
Armed with some good understanding of the requirements of the application – based on the existing product, interviews and user stories conducted by the programming team – we set about work on basic wireframes to give shape to the core processes of the application. We translated ideas quickly sketched on paper into schematic illustrations to define the basic interactions and interface elements of the application and identify recurring design patterns.
Early wire-frame sketchesThe look and feel
Using the wireframes to identify common screen templates and interface patterns, we proceeded with producing a limited number of screen designs to start defining the feel of the application. While wireframes often tend to feel too abstract to non-developers, the screen designs provided a good reference for feedback at this stage. When they started feeling solid and provided the necessary amount of information, we next coded a static prototype in HTML and CSS (2) in order to test the validity of our interface ideas so far before programming of the application logic began.
A very important aspect of the application was the output of well-formatted report, and a lot of effort was put into developing a coherent language for them. We designed a multitude of different types of reports in InDesign before coding HTML/CSS prototypes that served as templates for the end-product PDFs, which are rendered on demand through the application.
Reports designed in InDesignGoal-oriented design
The core of Feesability is built on the idea of using standardised codes for describing Tasks and Activities. While not necessarily immediately obvious to every new user, we believe the processes introduced in Feesability will soon feel familiar and intuitive. Every effort has been made to create a goal-oriented interface that guides the customer to best practices while speeding up the process of compiling budgets.
Design credits:
Interface design, wireframes, and design templates: Fredrik Jönsson, Ummocrono
Reports design: Nina Wollner, Ummocrono
Interaction Design, Ruby on Rails programming: Matt Ford, BitZesty
Notes:
(1) The original Feesability application was a desktop software developed by Feesability co-founder Dan Tench back in 2000. It was programmed in Visual Basic and enjoyed some limited use in-house.
(2) Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation semantics (the look and formatting) of a document written in a markup language.

