Many approaches and an arsenal of activities and disciplines exist for the execution of UX design. This post describes the UX design approach according to the book The Elements of User Experience which will be applied for CoffeeBoy. Thereby we’ll distribute the respective activities and disciplines that we’ve seen in the UX Design Basics, Part I post onto five planes.
The UX design approach applied for CoffeeBoy will traverse through five planes as described by Jesse James Garrett in his great book The Elements of User Experience (2002). As shown in the below diagram we’ll start on the bottom strategy plane and finish on the surface plane:
Each plane will build on the decisions made in the previous one and will include UX design activities and disciplines which will be utilized to generate those decisions. Thereby the nature of the decisions will change from abstract to concrete the more we’ll traverse from bottom to top. Let’s see in the following sections which activities and disciplines each plane will contain.
We’ll start on the bottom strategy plane. There we’ll answer the following essential strategic questions:
- Why we and the rest of the world might actually need our product?
- What do we want to achieve with our product?
- Who are the potential users of our product?
- How can we satisfy our users’ needs and desires with our product?
In order to find answers to these questions, we’ll slip into the role of the broodforce Ltd. CIO Pete (broodforce Ltd. will be introduced in the next post), tell how the idea for CoffeeBoy evolved, infer first must-have features from the idea, and define further must-have features with the aid of our broodforce Ltd colleagues. By defining the strategy for the brand and image of our product we’ll also think about how CoffeeBoy should be perceived by our users. Then we’ll charge a UX agency with user segmentation and user research. Finally we’ll create our product’s personas based on the information delivered from the UX agency. Sounds like we’ll have a lot of fun, huh? 🙂
The strategy plane will (hopefully) deliver valuable insights about (1) what we want to achieve with CoffeeBoy and (2) what our users may expect from our product. On the scope plane we’ll distill those insights into requirements. Thereby we’ll first turn on our creative imagination and create scenarios which will narrate of our personas interacting with CoffeeBoy in their everyday life. These scenarios will eventually produce further requirements and therefore ensure that we’ll have considered all use cases. At the end we’ll divide all requirements up into data requirements and function requirements as well as decide which ones will be build into the first version of CoffeeBoy.
The input into this plane will be in each case a list of data and function requirements. By applying information design and interaction design we’ll structure these requirements into groups of related data elements and function elements. Thereby the term element describes an abstraction of a user interface element like a text label or a button. Then we’ll allocate these element groups to user interface pages and page sections. For example, if we would have a lot of data and function elements dealing with application settings, then we typically would allocate them to a Settings page. The Settings page in turn could be divided up into different page sections like General Settings and User Profile Settings.
The structure plane will also be the place where we’ll design the navigation structure (i.e. the relation between pages), plan a consistent handling of exceptional situations like errors or warnings, as well as introduce a consistent user interface language by means of a glossary.
With the structured data and function elements in hand we’ll decide on the skeleton plane how those elements will be represented and arranged in the CoffeeBoy user interface in order to provide optimal usability. Thereby we’ll apply interface design and create mock-ups of the user interface’s pages. Each page mock-up will now contain concrete representations of data and function elements like e.g. text labels resp. buttons. Furthermore we’ll decide how these elements will enable orientation (“Where are we now?”) and navigation (“How and where can we go from here?”). The mock-ups will not yet reveal information about the visual appearance of the user interface. This will be our duty on the next plane.
On the last plane we’ll decide on the colors, fonts, graphics, sounds and animations which will be experienced by the user on the surface. These sensory creations will not only serve to define the aesthetics of CoffeeBoy, but rather to enable best possible usability. For example, by coloring a button red on a page with mostly black, gray and white elements we could emphasize this button’s importance.
It’s planned to adopt Google’s Material Design principles and to apply the Angular Material Design library. This may eventually have an influence on the decisions made on the skeleton and / or the surface plane.
The traversal from plane to plane won’t be sequential, but rather iterative. That’s because some generated decisions may cause a rethink of decisions made on a previous plane. For example, a scenario on the scope plane may generate a new idea which again may cause an adjustment of the strategy on the plane below.
This five plane approach will encourage us to go step by step until all decisions are made, and not over-hasty dive into the development process without thinking through the design. Therefore on each plane a new decision should be made on the basis of at least one decision from the previous planes. If there isn’t one, then we should eventually go down the path until we can reason this new decision.
In order to illustrate why this is important, let’s say we’ve made a decision on the surface plane to display the user’s identity information by means of her photograph and her user name in darkblue font, which in turn may be based on the decision on the skeleton plane to present the user’s identity information by means of click-able image and text link elements, which in turn may be based on the decision on the structure plane to put the user’s identity information to the page’s top right corner, which in turn may be based on the decision on the scope plane to build in a user identification feature into our product, which in turn may be based on the decision on the strategy plane to store data in a database on the server (which, of course, requires a unique assignment to a user) because that’s ok for our users.
If we would, however, not answer the strategic questions on the first plane, then we would eventually ignore the fact that our users don’t want to store their data in our database, but rather in their browsers. This fact would make the user identification feature completely needless.
This post already mentioned broodforce Ltd., the company at which we’ll develop CoffeeBoy. Before we’ll begin to work out our product’s strategy we should understand broodforce’s strategy first. With the next post we’ll also finish the introduction phase of this series. Stay tuned!