In Adobe Experience Manager, the core of a great user interface includes everything from flexibility for content types, adaptability for different user groups, and an efficient authoring process. Before development even starts, much consideration should go into how the web design structures will accommodate all these use cases.
The overall site-structure is based around page templates and components. Designing for an AEM website requires thinking around the atomic design methodology. The templates can be defined by different design elements (atoms, molecules, and organisms), as well as any combination of the elements. Visual design styles, such as labels, inputs, and buttons can be combined to create a search component. Further combinations would produce more complex components of the UI, such as the complete navigation. Each component is modular, re-usable, and has a specific functionality to display your content. These are the building blocks to your web design.
Although each template is broken down into self-contained components, there needs to be scalable design criteria. End users, authoring the experience, will have the ability to configure components with RTE text, images, form fields, and a multitude of other options. One unique component, such as a hero area, may have a number of factors, but the delivery of the appropriate content is based on authentication (anonymous vs logged in), content type (text, image, or video), and perhaps responsive considerations. The designer must find relationships between template and component pairings and be able to reuse as many design elements as possible to prevent duplicate development work (or time spent refactoring a new variation).
Creating a UI styleguide can help to identify design patterns and standards, as well as enable developers to create maintainable code. Break down the experience into similar elements and then into groups based on content use cases. A clear design framework should be created where it can easily be updated by a client’s design team and referenced by developers. Also establish common vocabulary to easily reference components and naming conventions between teams and for the developers.
In order to mitigate risk of breaking the design, authoring restrictions may be introduced such as setting character lengths, image sizing, or even where the component is allowed to be placed on a template. Consider documentation or annotations on usage guidelines or within your UI styleguide.
As part of the hand-off to front-end developers, there may be confusion around UI interaction or responsive functionality. Assisting documentation, such as wireframes, gestures, or choreography can help outline interactions within the component design. Proactive front-end developers should expand upon the UI documentation by creating a prototype that demonstrates the intended capabilities of each component.
UI design requires a level of predictability and accounting for multiple use-case scenarios based on authoring needs. Play the ‘what if’ game and think about how each component has the potential to be expanded (or even break) from the authoring options available. How could the design change or evolve over time? How will your assets be used or enhanced in the future?
Best of luck when creating your next design.