“ The Web is a participatory, voluntary medium, and your visitors are in control not only of what they see, but even how they see it.”
~ Bryan & Jeffrey Eisenberg, in “Call to Action”
|This article is a precious part of the hybris Project Patterns series.|
A great number of e-Commerce projects feature complex and innovative front ends. Companies invest significant labor to create a representative new digital face for its Consumers.
The Business is usually focused on creating the ultimate User Experience, which - in turn - would ensure better traffic and conversion. This venture involves inspiration and creativity, but also knowledge in modern e-commerce trends.
Consequently, in those projects, most of the functional specifications, we see, refer to the front ends. Processes, page flows and business rules dominate those functional documents.
However, repeatedly, the specifications forget to consider the complete assortment of pages, involved in the User Experience and the corresponding User Interfaces (UI).
Unclear overview of all User-facing pages involved in the Front-End User experience, which results in a trifold problem:
Create an Inventory of pages and other visual artifacts.
Client, Overall Consulting, hybris Functional Consultant, Workshop, Domain Methodology, Software Methodology, Glossary, Requirements Gathering, System Actor Inventory, Internationalization, User Experience Design Planning, Communication, Back Office Usability, Business User Enablement
Thinking in Pages
Thinking in terms of pages helps the Business users to form a balanced view of the desired functionality and the associated workload to develop it.
Consider the following common activities related to the realization of one single front-end page:
These activities contribute to the overall effort and budget of the project. Not to forget also the usage of tools used for the same activities, the corresponding planning and synchronization with other project accomplishments (like prioritization of implementation and testing).
Hence, having a good overview of all pages involved in the construction of the (web)site, is an essential step towards proper estimation of workload, resources and costs.
In a recent project, during a Workshop, we were engaged in a discussion about the “User’s Account” portal – a relatively common feature in a B2C context. Reviewing the initial estimation of screens revealed that all major functions of the portal were associated with single pages, for example, one solitary page for each of the features like “My Information”, “My orders”, “My favorites”, “My loyalty points”, etc.
After a closer inspection of those functional areas, we drew the Client’s attention that some areas are represented not by one, but by several pages. For example, the block “My Orders” corresponded to screens like “Orders overview”, “Order Details” and “Order Update”. Therefore, the initial workload associated with this block became triple, and consequently, the involved effort.
As a result, we signified in our page-specification document that the number of pages for this block is higher than 1. This approach gave the Client an indication that they need to spend more quality time to plan the design of those pages and reconsider their complexity.
Further on, mobile devices also demand dedicated sets of pages, which match their size and kinematics. Conforming to modern responsive designs and gadget capacities, essentially, defines new dimensions in how we approach the whole User Interface universe.
Introduce the Pages Inventory Artifact
As a Consultant, present to the Business Client your knowledge about the pages, which need to serve a common e-commerce application. Consequently, already in the inception phase of the project, initiate a Pages Inventory document.
This deliverable ensures the completeness of the overall page set and aggregates essential page information, such as:
- Page names,
- Page types,
- Page descriptions,
- Existence of page designs i.e. Visual Design (VD)
- Existence of page kinematics i.e. Interaction Design (ID)
- Affiliation to a specific device, environment or a channel
- Localization aspects
- Page template, which predefines the layout of the page
- Page components restrictions,
- User types or personas, who would use the page
- Personalization specifics
- Page management aspects
Given the critical information contained in the Pages Inventory documents, during the lifecycle of the project, we use them as a primary input for the following activities:
Pages Inventory can be presented in a graphical or tabular format.
Here is an example of a graphical Inventory, I employ in projects. It is used mostly for illustrative purposes, but also to challenge the existing comprehension of the User’s journey.
Below is an example of a tabular Inventory – commonly used in projects. This format is especially useful when collaboration in this document and accuracy of data is essential for the progress:
hybris’ Pages Inventory
When starting on a new project, it is worth also to have a look at the list of pages used by the hybris Accelerators. Based on common e-commerce practices, the various Accelerators offer predefined collections of pages suitable for certain domains, like fashion, retail, telecommunication, mobile, etc.
The Accelerators are well documented with descriptions of their front-end artifacts, layouts and componentization.
Based on the initial analysis of the desired user experience, you could consider following the pattern User Experience Design Planning when preparing the ground for the website. This decision will influence the creation of the Pages Inventory document.
To summarize, in case of an Accelerator-driven design you would have a good jump-start with predefined descriptive information for your pages. On the other hand, creating own custom-made design has the advantage to use a representative corporate Look-and-Feel, by still using the Accelerators’ layers for integration with the remaining hybris core.
Pages are building blocks for the front ends. The names of the pages are used during the project lifecycle for reference and specifications.
|Hence, consider adding the pages to the project Glossary, in order to standardize a “visual” dictionary exploited by end users.|
To have an overview of pages, project teams often rely on Site-maps. Even though, a site-map document could provide an overview of all pages included in the solution, often we find it insufficient, because the site map frequently does not list all types of pages or all pages.
The Pages Inventory documents can contain an exhaustive list not only of pages, but also of all other user-facing artifacts like pop-ups, messages, components, dialogs, wizards and emails. Every one of those items comes with own workflows and behavior. They require dedicated interactions with the end users and contribute to the overall User Experience. Therefore, the business value they bring is significant.
For that reason, the overall effort involved in creating those additional artifacts is not negligible and deserves right attention in registering, planning, designing and realizing.
A point, regarding the Back Office and the accompanying pages: A Back Office also offers a User Interface for users who need to administer the various data.
Because the Back Office UI offers specialized User experience, it would be right to expect that we define and discuss user pages for the Back Office (BO) as well.
hybris suite is equipped with a set of BO User interfaces, called cockpits, which allow dedicated personnel to manage and organize data. Those cockpits are already supplied with predefined set of pages and therefore, they normally do not require inventarization.
However, in more complex realizations, where the cockpits need to facilitate new processes or screens, you might need to define extensions to the cockpits, design new pages and redefine existing workflows. In those cases, the Back Office Usability is essential for the final Business User Enablement.
Business-to-Business (B2B) and Business-to-Consumer (B2C)
The two major flavors of e-commerce sites – B2B and B2C – also introduce diversity in page variety and workflows. Exploring those onto a graphical Pages Inventory, would result in a diagram similar to the one below:
Nevertheless, regardless of the flavor, remember, that commercial sites are not only B2B or B2C; they are primarily P2P – person-to-person. Therefore, discuss with the Client all aspects of their front-ends and possible variations, in order to create a website, which brings harmony and confidence.
The page inventarization cannot be complete without a proper explanation of the pages themselves. Page descriptions are critical requirements artifacts, which provide the most detailed information about individual pages.
In terms of Interaction- and Visual Designs (ID and VD) Page Descriptions prove to be a reliable and structured source of information when it comes to front ends.
As a consequence, the fine-tuning of workload estimation can be done for each page.
A Page Description document should contain details about the purpose of the page, its users and Call-To-Action (CTA) elements.
Describing the purpose of the page and its usage can be done in a narrative way. The various visual elements of the page together with their CTAs can best be described by using the zoning technique.
Zoning is applied by indicating all significant areas of the page and describing them in a table. The table then contains a list of all visual elements (VD), their place on the layout (VD) and their reaction to users’ behavior (ID). Additional information may include dimensions, compulsory fields, type of the element, default value, acceptable values, validation rules, etc.
Here is a simplified template for a Page Description:
The Pages Inventory and the Page Descriptions documents are interconnected: The Page Inventory should be your leading artifact to provide an overview of pages and overall estimation of work. However, the Pages Descriptions will contain all nitty-gritty details of each page, response to user activities and possible transitions to other pages.
In hybris projects pages are composed by reusable visual components. The Accelerator framework comes with a number of ready-to-use page components. However, the project may require the use of custom components with complex behavior. In those cases you may opt for creating also a Component Inventory artifact and the corresponding Component Description documents. In that case, the Page Descriptions would refer to the Component Descriptions, when a component is used within a page.
Let us take for example the page Header and Footer: those are common elements for every page on a website. You can distill their visualization and behavior in separate components. And refer to them in every Page Description, instead of repeating the information.
Putting it all together, when approaching a hybris project, consider using a Pages Inventory document and complement it with Page- and Component descriptions.
Those artifacts are a vibrant part of the Requirements Gathering process. With them, you would be able to guide the Client towards complete and comprehensive front-ends. For that, make sure your Pages Inventory documents are up-to-date and visible throughout the entire project.
|~ Did you like this article? Please let us know ...||