Our UX design process continues on the structure plane. Here we’ll perform a series of design steps which will put out essential insights about how the data and functions will be distributed across the UI, which views the UI will feature and how the user will be able to interact with it. This post gives a short introduction to this structuring process. As a first structuring step we’ll then group our requirements.
What’s up on the structure plane?
As introduced in the UX Design Process for CoffeeBoy post our goal on this plane is to structure the UI based on the requirements coming from the previous scope plane. Now when talking about structuring in this context we concretely mean a wise distribution of data and functions across multiple UI views1 that suits best for our personas Amy and Bob, as well as a definition of how the UI should behave and change its shape as an answer to user actions (as e.g. button clicks) or events coming from the Coffee Machine component (as e.g. exceptional conditions like lack of ingredients to brew a cup of coffee).
During a series of posts we’ll run through an iterative process which will contain the following steps:
- Grouping the data requirements.
- Grouping the function requirements.
- Building high-level requirement groups showing a rough UI structure.
- Deriving use cases from the high-level requirement groups.
- Formalizing the use cases by means of interaction flow charts.
- Including a navigation concept into the use cases.
- Deriving views from the use cases.
- Creating a site map based on the navigation concept and the views.
- Creating a layout concept and dividing the views’ data and functions into sections.
- Enhancing the glossary with new terms emerging in the whole process.
Our decisions made during the above structuring process will of course be strongly driven by the knowledge about our personas. For example, Bob is not the primary person, though he should at least be able to make a single cup of coffee. So when designing the single cup of coffee order use case we’ll have to consider a very simple interaction concept taking into account Bob’s low technical experience.
At the end of the structure plane we’ll be able to lay the foundation of the construction phase and define first scrum themes, epics and stories.
Results are subject to change
While we’re in a highly iterative process the results of all process steps are subject to change. That’s because each process step generates new insights and ideas. Hence results generated in one process step may cause changes of results made in an other process step. As already mentioned in the previous post all results are hosted in the broodlab GitHub repository, so one can perfectly follow changes between result revisions. Links to individual results will be provided in each process step.
Until now our data and function requirements are listed completely unrelated. In the following we want to change this and group them in order to create a rough structure of the CoffeeBoy UI.
As a first step we leave the flat structure of the data requirements and create complex data structures with hierarchies and properties. However, the complex data structures won’t necessarily be the same in the later implementation model. It’s just a first shot towards a better organization. Then we allocate the function requirements to small groups of related functions.
As a second step we build high-level groups out of the data and function requirement groups. The high-level groups constitute a rough structure of the CoffeeBoy UI:
We can see that the four high-level groups exactly match the must-have software features we’ve defined on the strategy plane. Though compared to the features the names slightly changed, so here’s a mapping:
- Cup(s) Of Coffee Order and Brewing Process <=> Ordering Cup(s) of Coffee
- Coffee Recipes <=> Coffee Recipe Management
- Inventory <=> Displaying Ingredient’s Fill Level
- Maintenance <=> Displaying Cleanliness Status
Remarks to the requirement groups
Out of all requirement groups we can expect the most design challenge within the Cup(s) Of Coffee Order and Brewing Process group. It features the most function requirements and therefore has many interaction options for our users. While we can expect Amy to welcome a flexible UI giving her all options on a small scale to efficiently order one or more cups of coffee, we should nonetheless keep complexity down for Bob. For that reason we should consider two dedicated interaction concepts: one for an single cup of coffee order focusing Amy and especially Bob, and one for a multiple cups of coffee order focusing merely Amy.
Furthermore the ordering and brewing processes strongly depend on external states as the availability of enough empty cups on the tray or ingredients in the inventory. It will be an interesting challenge to design a feedback concept informing our personas about such issues at the right time and place.
The Coffee Recipes group contains plain old CRUD functions, presumably not blowing up much dust with regard to interaction design.
Finally the Inventory and Maintenance groups will produce views simply displaying the ingredients’ fill level respectively the maintenance status. The Maintenance group will furthermore allow the user to start the maintenance process in order to clean CoffeeBoy’s inner tubes and stuff. For consistency reasons the maintenance process should be designed like the brewing process. While there should be dedicated views for displaying the ingredients’ fill level and maintenance status on the Remote Client for reasons of limited space on the screen, we might consider displaying these data on each view on the Local Client.
In the next post we’ll derive use cases from the requirement groups. Stay tuned!
- Here the term view is used as an abstraction for a UI page or page section. ↩