08 Sep

User Experience Design Planning



“Design is not just what it looks like and feels like.
Design is how it works.”

~ Steve Jobs

This article is a precious part of the hybris Project Patterns series.

There is rarely an e-Commerce project without a Consumer-facing front-end. To meet the high demands of an attractive website, the User Experience Designers (UEDs) spend a good portion of time to construct the next generation Corporate site.

In addition to dealing with trivial needs like high-usability and user-friendliness, the UEDs face the overwhelming must-haves of modern sites, related to hybrid-channels, retina displays, responsive design, cross-browser compatibility, brand-awareness and personalization.

Often, a hot topic for discussions is the planning of the User Experience Design (UED) activities, which depend so much on the Business’ input. On the other hand, UED is an important precondition for the complete realization of Consumer front ends.

To implement a business requirement with front-end elements, a hybris development team uses the production from the UED team, creates front-facing code (like HTML) and integrates it with the hybris code.

In the course of a hybris project there would be a decent number of front-end pages. Hence, one can imagine that the readiness of User Interface (UI) artifacts impacts significantly the overall development planning.


Repeatedly projects experience lack of coordination between UI work and hybris implementation work. If not planned in sync those two development tracks produce heavy dependencies and delays. Technical teams face significant UI rework, in case they start on production with incomplete UED. Moreover, as commonly happens, the UED is created by an external to the project agency, which makes the overall planning even more challenging.


Plan the UED efforts in parallel to the core development tasks. Resolve dependences by careful prioritization of UI and other system requirements.

Related patterns

ClientOverall Consulting, hybris Functional Consultant, Workshop, Domain Methodology, Software Methodology, Glossary, Requirements GatheringSystem Actor InventoryPage Inventory, Communication


Understand the Role of ID and VD

Aiming at superior User-Centric Experience, two design activities become prominent when defining the look-and-feel of a website – Interaction Design (ID) and Visual Design (VD).

Essentially, Interaction Design (ID) focuses on the mechanics of the user interface, ensuring that it follows established workflows, meets end-user process needs and conforms to corporate polices.

Visual Design (VD), on the other hand, addresses the aesthetics of the User Interface, focusing on coloring and imagery, eye-catchiness and company’s graphical guidelines.

ID and VD are important rudiments of the overall delivery, when a conceptual design of the future solution is outlined.

In practice, project deliverables like System Actor Inventory and Page Inventory influence heavily the scope of the UED efforts: actors will affect the desired User experiences, and the pages will determine the volume and complexity of the user-interface work. 

It is for that reason that UED chores should be planned with care together with the analysis of system actors and Consumer-facing visual artifacts, like pages, editorial components, dialogs, pop-ups, wizards and emails.



Plan Your UED Activities

User designs gather knowledge about the interface used by the Consumers and set the base for the end-user experiences. UED tasks are concerned with the realization of mock-ups and system prototypes, with persona analysis and usability tests. Those activities need to be performed before the actual coding starts. Consequently, in projects, we pay special attention to the planning of those activities in respect to the rest of the development efforts.

My ever-favorite approach in planning UED activities has been inspired by the study of Lynn Miller and Desiree Sy “Adapting Usability Investigations for Agile User-Centered Design”. It represents a proven technique towards aligning the UI tasks with the rest of the development process.

The study recommends an agile iterative approach, where working versions of the software are delivered in short increments, called iterations.

Miller and Sy suggest separating the UED iterations from the implementation iterations. In essence, the approach is to have two parallel production tracks: iterating the design and implementation tasks independently, but simultaneously. The UED track provides deliverables at least one iteration ahead of the corresponding development cycle.

In the lifecycle of a project, the UED is given a head start through a combination of initial discovery Iteration 0 and a development Iteration 1 with focus on non-UI related deliveries, like data modeling or integration analysis. After that iteration, the UED would provide relevant UI artifacts to the development track.



In several consecutive projects I noticed that “one iteration” was not sufficient for the development team to “get ready to use” the provided deliverables from the UED team. In most of the cases the visual artifacts were delivered by an external creative agency, which did not have experience in hybris projects. They were unaware about the technical requirements of the platform to provide the final HTML snippets for the implementation.

Our UI team needed to transform the deliverables into HTML artifacts and validate them with the rest of the business requirements, before the actual assembly of User Interfaces with hybris business logic. So, in fact, our UI team became “the” UED team in the Miller-Sy strategy.

In those projects, we’ve applied an adapted version of the Miller-Sy approach, which allowed us proper timing for functional review and iteration planning.

In short, the major adjustments included:

  1. UED artifacts are provided at least 2 iterations before the development iteration to the internal User Interface team.
  2. The User Interface team “cuts” the UED artifacts into HTML code, conformant to the hybris design guidelines. The resulting artifacts are handed over to the Functional team one iteration before the development cycle.
  3. The Functional team validates the final UED delivery with the rest of the business requirements and prepares a complete functional specification for the development cycle. Technical review about feasibility can also be done in this cycle.
  4. At the start of the development iteration, the Technical team accepts the complete UED delivery, and starts the implementation. 


“One-team” Mentality

The proposal of working in separate tracks does not impose an opinion that the teams are separate and only exchange deliverables. I am not alone in thinking that the quality of the final solution is a responsibility of each project member, not only of individual teams or departments. Therefore, the mindset of “one team” is vital in making the project a real accomplishment.

Miller and Sy also concur that, regardless of the division, the UED and development teams work in close cooperation should they wish to deliver value to the Business users. 

Keep your Visual Designers close to the rest of the team, so that they can easily make changes when needed.

Use proper Communication channels, Workshops and status meetings to ensure collaboration between teams.


Custom Design or Accelerator Design?

As seen, when entering a hybris project, the Business Client begins with an extended ID/VD effort, which is commonly out-sourced to an external design agency. As such, these two activities traditionally follow company’s preferences and corporate taste. Even though the ID/VD deliveries are mostly about providing a visual skin around graphical elements, colors, markup, and fonts, they influence significantly the workflows and end-user behaviors.

Contrariwise, in order to reduce time and cost, the Client is often attracted by the idea to follow the “hybris Accelerator approach”, namely to start the initial front-end design with the visual framework offered by the hybris Suite – the Accelerators

The hybris Accelerators are ready-to-use software modules providing fully functional front ends. Each Accelerator incorporates common e-commerce practices for realizing multi-channel solutions, offering comprehensive workflows for an online store, order handling, and Call Center capabilities. In its architecture each Accelerator provides:

  • front-facing code artifacts, which define web pages and their visual elements
  • business logic, acting as a façade layer, connecting the front-end artifacts with the core hybris modules
  • rich data model and several complete store-fronts

Dedicated hybris Accelerators facilitate the quick realization of various business e-commerce domains, like B2B, B2C or Telecommunication. Each Accelerator captures the specifics of the corresponding domain and provides a programing model for extensions.


It is a strong demand of hybris projects to utilize the Accelerators “as much as possible”. This approach influences the estimated development effort, because it suggests the usage of out-of-the-box default VD/ID, provided by the Accelerators.

And here comes the challenge: a hybris Accelerator has own way of defining page flows, layouts and user experiences, which could be very different than the Client’s vision about the same. It becomes apparent that a gap exists between the desired UED and the proposed – by the Accelerator – ID/VD.

When the Client wants to explore the Accelerator’s strategy, the Business users often find themselves adapting their own ID/VD towards the Accelerator’s flows and page layout. Which, in turn, increases the development effort of UED.

The other alternative is to follow the own ID/VD and adjust the Accelerators. When the Company’s proprietary design is leading, the default proposition of the hybris Accelerator layer needs to undergo customizations, in order to adapt. That challenges the main purpose of the Accelerators, namely, to serve as a trampoline for building quickly the desired front ends.

A practical solution to these two scenarios is to align up-front the expectations of the Business people about the design – early in the project, in a dedicated UED Workshop – and decide, which approach to take: own ID/VD or Accelerator’s.

If a decision is made to follow the Accelerator designs, consider applying a lightweight own ID/VD. Still ensure that you not forget to estimate some ID/VD efforts in order to get a corporate look to the new site.

If a decision is to rely primarily on the own UED, make sure that the Client is aware of the increased development efforts. This approach does not impose the idea that you would completely abandon the Accelerator’s benefits: the custom design can still profit from the accelerator’s framework, which offers rich connecting points into the hybris Multichannel Suite modules.


Summary Points

When having a hybris project, which depends exclusively on Consumer-facing visual deliverables, consider the following ideas:

  • Spend time to elaborate with the Business Client on a suitable UED approach – corporate or Accelerator. Use your knowledge in similar projects to explain the rationale behind each choice.
  • Plan, with care, the synchronization between UED and development cycles.
  • Consider applying the hybris’ guidelines for design agencies when going with the Accelerator approach.
  • Ensure that all teams involved in the production process – UED, functional and technical – trully collaborate and back-up each other. 


  Continue reading:


~  Did you like this article? Please let us know ...  


Total votes: 0