In Adobe Expe­ri­ence Man­ag­er, the core of a great user inter­face includes every­thing from flex­i­bil­i­ty for con­tent types, adaptability for dif­fer­ent user groups, and an effi­cient author­ing process. Before devel­op­ment even starts, much con­sid­er­a­tion should go into how the web design struc­tures will accom­mo­date all these use cas­es.

The over­all site-struc­ture is based around page tem­plates and components. Designing for an AEM web­site requires think­ing around the atom­ic design method­ol­o­gy. The tem­plates can be defined by dif­fer­ent design ele­ments (atoms, mol­e­cules, and organ­isms), as well as any com­bi­na­tion of the elements. Visual design styles, such as labels, inputs, and but­tons can be com­bined to cre­ate a search com­po­nent. Fur­ther com­bi­na­tions would pro­duce more com­plex com­po­nents of the UI, such as the com­plete navigation. Each com­po­nent is mod­u­lar, re-usable, and has a spe­cif­ic func­tion­al­i­ty to dis­play your con­tent. These are the build­ing blocks to your web design.

Although each tem­plate is bro­ken down into self-con­tained com­po­nents, there needs to be scal­able design criteria. End users, author­ing the experience, will have the abil­i­ty to con­fig­ure com­po­nents with RTE text, images, form fields, and a mul­ti­tude of oth­er options. One unique com­po­nent, such as a hero area, may have a num­ber of factors, but the deliv­ery of the appro­pri­ate con­tent is based on authen­ti­ca­tion (anony­mous vs logged in), content type (text, image, or video), and per­haps respon­sive considerations. The design­er must find rela­tion­ships between tem­plate and com­po­nent pair­ings and be able to reuse as many design ele­ments as pos­si­ble to pre­vent dupli­cate devel­op­ment work (or time spent refac­tor­ing a new vari­a­tion).

Cre­at­ing a UI styleguide can help to iden­ti­fy design pat­terns and standards, as well as enable devel­op­ers to cre­ate main­tain­able code. Break down the expe­ri­ence into sim­i­lar ele­ments and then into groups based on con­tent use cases. A clear design frame­work should be cre­at­ed where it can eas­i­ly be updat­ed by a client’s design team and ref­er­enced by devel­op­ers. Also estab­lish com­mon vocab­u­lary to eas­i­ly ref­er­ence com­po­nents and nam­ing con­ven­tions between teams and for the devel­op­ers.

In order to mit­i­gate risk of break­ing the design, authoring restric­tions may be intro­duced such as set­ting char­ac­ter lengths, image siz­ing, or even where the com­po­nent is allowed­ to be placed on a template. Consider doc­u­men­ta­tion or anno­ta­tions on usage guide­lines or with­in your UI styleguide.

As part of the hand-off to front-end devel­op­ers, there may be con­fu­sion around UI inter­ac­tion or respon­sive functionality. Assisting doc­u­men­ta­tion, such as wireframes, gestures, or chore­og­ra­phy can help out­line inter­ac­tions with­in the com­po­nent design. Proactive front-end devel­op­ers should expand upon the UI doc­u­men­ta­tion by cre­at­ing a pro­to­type that demon­strates the intend­ed capa­bil­i­ties of each com­po­nent.

UI design requires a lev­el of pre­dictabil­i­ty and account­ing for mul­ti­ple use-case sce­nar­ios based on author­ing needs. Play the ‘what if’ game and think about how each com­po­nent has the poten­tial to be expand­ed (or even break) from the author­ing 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 cre­at­ing your next design.