Differences Between Website and Enterprise Software Design

In my last post, I described (SDL Web) product ideas and the user experience. I continue by contrasting design for website visitors versus for those that manage such websites and end with a thank you and invitation.

Disclaimer: these are my personal views, biased by a business analyst and CMS background and lots of love for my product and its community.

Design Alignment

The biggest difference between working with our customer's designers and SDL's UX team is the organizational alignment. As part of a given customer's digital experience ecosystem (read about being a Good Corporate player by Nuno Linhares) the CMS implementation is often downstream of Web design where the user experience design, wireframes, and even HTML often come before the CMS implementation. The goal of "happy customers" is the same, but the definition of customer isn't. Your persona is not my persona.

When Alignment Works

The best digital agencies and front-end designers understand content modeling and content strategy as they create great experiences for website visitors that the CMS and developers can implement and support. They think semantically, adopt approaches like BEM, and follow thought leaders like Gerry Mcgovern or A List Apart. They look holistically at website visitor goals to help solve real business and user problems.

The Pain of Misalignment

I haven't seen horrible designs in my projects, just the occasional design that didn't quite meet editor expectations that didn't account for long text, more/less content, and other changes to managed multilingual websites. Completely disregarding the existing content/data models and technical constraints means a website design isn't just a design, it's a proposal with new requirements and functionality. Often I've seen what Gerry McGovern would call "tiny tasks" creep into the design, to the dismay of the website builders and eventually users.

New requirements and functionality aren't bad on their own. It depends on what business problems you're trying to solve beyond "a shiny new website." This brings us to our own designers and UX team. When looking at our editorial and developer scenarios, we have to balance desired functionality with existing data models and constraints.

Web design is great when aligned, otherwise in a misaligned corporate Web development environment, you might see familiar elements of this amusing IT meme:

View post on imgur.com

Solving Business Problems

Though there's some overlap with typical website visitors, our users are corporate employees, contractors, and consultants that have built "business critical" systems with our software. Our disciplines each have their focus to support an innovative user experience. Philipp explains better with this slide:

Source: Building the UX Community at SDL

User Experience Community 

Though Product Management has plenty of product experience (a few decades worth combined), to continue to evolve the product lines we work with UX and Engineering to innovate in the intersection between people, business value, and technology.

With hundreds of Tridion-related blog posts and even more Tridion questions and answers, I'm fairly comfortable working in the open. If you haven't had the chance, give us feedback, share your ideas, or mention your open source project in the posts and sites below. Be sure to participate on SDL Community.

• Tridion Stack Exchange Meta (discussions go here)
• Example Tridion Reports
• Commenting Features
• Common Rich Text Format Areas
• TDS Summit Ideas
• Your Open Source Project
• SDL Tridion Ideas (we're considering a new place for ideas, but submit ideas here until things change) 
• SDL Community
• The SDL Web (Tridion) technical group (follow the technical community here)
• SDL UX group (New! Join this group, seriously.)

Oh and thank you. From my first posts on the old forum to an unexpected community award (awesome!) to the many times I was corrected learnt something new, you've helped me solve problems and better communicate solutions. It's been an amazing experience so far that incidentally turned into practical training for my new role.

Tridion User Expectations for the HTML Design (and beer metaphors)

I'm wrapping up my most recent visit to the Amsterdam office. One of my colleagues had a prompt from a client on what to request from the creative agency in terms of the markup. Of course we had to compare notes.

We gathered our "best practices" but needed non-technical descriptions for the business user communicating their preferences to the creative design agency (if you really want the technical details take training and/or read this post by Frank M Taylor).

So let's look at some user stories for those using an in-context CMS editor:

"As a CMS user I need the ability to add content to and from the page. I should be able to add, re-order, or remove content in the in-context or form-based editing interfaces."

This translates into movable elements. Lists and “flat” markup are preferred where possible—especially on a page. This lets editors add, move, or remove in the Content Manager and Experience Manager.

You don't need markup to see which is easier to manage. Here's an example from our CMS Design Principles training: perhaps your presentation looked like a box of sorts:

A B C

D E F

G H I (that's the end of the training example, the rest is my metaphor)

Would you prefer a list that automatically displays in rows?

Fields and Folders are about the How not the What

Imagine being a Tridion consultant, helping content authors with setup you're not quite familiar with yet. You're asked:

"What does this field do?"

That can be the most embarrassing and challenging question I get from content authors when looking at an unfamiliar SDL Tridion setup simply because the entry forms are templates are configurable, programmable, and extensible.

Related to this is, "Where should we put these items?"

This one is slightly easier because the answer depends on the update process in terms of:

• Who updates them
• What types of items are they
• Where are they used?
• How frequently are they updated?

The answer to both these "what" and "where" questions should be a "how."

One SDL Document by Document

I previously mentioned the rebranding and SDL Tridion 2013 SP1 updates my team’s applying to the Education materials.

Part of this is using updated templates. My philosophy again is to rely on your company’s experts at handling the bulk of writing standards and document templates. Here’s a quick tip on applying that brand new shiny Marketing PowerPoint template to an existing document.

In PowerPoint go to Design and click the Down Arrow in the Themes section.

Then simply find an open the .potx file to swap out the design.

Layouts that have the same name change automatically, however you may need to do two more things:

1. Change layouts (in the home tab) to the new versions
2. Change aspect (Design > Page Setup > Slide sized for) as needed if switching to a different ratio (e.g. from 4:3 to 16:9). One issue with changing aspect ratios is your images need to be re-scaled. See this older post by Microsoft’s Mary Feil-Jacobs on ways to do this which mostly still apply to current versions of PowerPoint (I like resetting images, but right now we have to update a few images and replace the old ones anyways).

For my slide update to “widescreen” I just needed to change the first drop-down to On-screen Show (16:9).

Documenting Component Presentations

This question came up today in a functional workshop:

"When and how do we document Component Presentations?"

A component presentation is the combination of a specific component and template. It becomes the rendered output to whatever digital channel you're managing. The basic, intuitive answer might be that we do not document these directly. We define the content management system and it's up to content authors to put in the "real" content. It's all structured and templated so we don't care, right?

Typically we define and confirm a few CMS elements:

• Page Types
• Content Types*
• Schemas
• Component and Page Templates

We define or specify individual components mainly through their schemas, which determine component fields and options. What about component presentations?