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.

It Starts with a Product Idea

You start with a fully-formed, marvelous idea for the product to solve your problem. This then gets reviewed to confirm its awesomeness and gets added to the product plan or backlog. From epics to stories to specifications to implementation, your idea gets transformed into one or more product features and is released to everyone, ready to solve the problem you had... two-to-three years ago.

Except that's not quite how it happens.

Lots of Familiar Ideas

In enterprise (possibly any) software development, the ideas are plentiful, evolving, and fleeting. Suggestions repeat and even compete with each other. Anamnesis reigns, where no idea is really new, just a recollections from past lives projects and other products.

For depressing inspiration on the relative importance of ideas, see Idea Guy Bill Gross's Ted Talk (hint: the idea is only part of the success equation).

As a product manager, I'm now part of a familiar process of prioritizing what we build without being too concerned with how it's built.

What I didn't tell you back as a functional consultant, the reason you liked (or didn't like) my functional designs was because of you, my dear technical consultant. I found a match between what the customer wanted and what you would likely implement.

• You liked automation and the Event System? Sure, it's part of the design toolkit.
• Content Delivery pro? Perfect, let's go dynamic with "widgets." Editor configures the Component, you deliver the results with a few Content Delivery API calls.
• Container components are your thing? Sure, we'll go modular but not dynamic just yet.

I helped discover the WHAT; you figured the best HOW.

Though technical formats should not dictate a proper content model, architectural and technical constraints actually help a design (see Design of Design, a nice follow-up Brooks' Mythical Man Month). In past business analysis roles I worked with developers and business owners to convert marketing and business owner wants into system needs.

Now I'm one of the "business owners." But my focus is still on helping the customer and their content editors.

Experiencing User Experience (UX)

I get to work with another awesome team that's even more focused and dedicated to the user's experience. As much as I loved working with implementation teams to build next generation websites, your personas were not my personas.

As a client, partner, or PS developer, you care about agile development processes, high-quality websites, and manage-able website code. Your primary persona is the website visitor rather than the editors. But the editors are my personas. And now you are also one of my personas.

Philipp Engel, SDL's UX Group Director, describes the team and the evolving process between Product Management, User Experience, and Product Development:

• UX Story Behind SDL CXC
• Building the UX Community at SDL
• And more recently, this introduction on SDL Community

Regardless of your experience with Tridion, please take a look at the slides, read the introduction, and consider joining the broader SDL UX community.

Beyond Feature Filtering

Having "field experience," I care about product features and have my own wish list of product changes. Paradoxically, the focus shouldn't be on features. If we look instead at what our users need to accomplish and what critical tasks they do over-and-over, we can focus on things we can improve qualitatively and quantitatively (read about data-driven design in our UX group).

A messier alternative is taking the few hundred (or thousand) ideas and then weight them by:

• Cost
• Appeal to stakeholders, the market, analysts
• Timing
• Size

But the point with feature ideas isn't to Catch Em All. You want a cohesive, comprehensible set, not a random selection filtered by attributes

Quick, pick the best ones by cost, appeal, or size. Source: Kotaku.

Discipline isn't just about saying "no." It's about saying "yes" to the right things. UX strategy helps us discover the right things based on the product vision and objectives along with well... the user experience. Organizations with "digital experiences" (websites) understand this and apply everything from A/B testing, to user research, to Top 10 Task Analysis to improve their customer's experience.

Since changing roles, editors are still one of my key personas and I'm still not responsible for the technical solution. I help highlight the problems; understanding the user's experience is critical to what we do. I'm looking forward to doing more than idea filtering.

In my next post I'll continue on user experience design, looking at some of the differences between website and enterprise software design and how the community can get involved.

What to Implement in Tridion First?

In a case of role-reversal from Functional Consultant to Product Manager, I'll soon have opportunities to prioritize development tasks.

I've told customers they might (should) prioritize based on their market/product/content strategy. For example, a client asked how to prioritize their website redesign from a Tridion perspective. After giving my feedback, the client pointed out my advice differed from my project manager. Oops.

• My Project Manager said to prioritize by difficulty.
• Separately, I suggested prioritizing following content strategy.

I was saved by the fact we were both correct from a CMS perspective. Combine perspectives to get some sagely advice:

Implement the harder, complex, and critical parts early. Use content strategy and business value to choose between tasks of equal complexity.

Use a top-down/outside-in approach to manage buildable sets of work for your sprints focusing on the hard, critical parts first.

1. Global “page template” elements (global navigation, footer, etc.)
2. Main editorial content and your main page/content types
3. Shared functionality that are not on all pages

Without page templates, you don't have pages. Without content, you don't have content.

Your content strategy is aware of quantity as seen in a content matrix, inventory, and/or sitemaps. From a CMS perspective there's value in “templating” something used 100s of times.

Remember that business value and metrics aren’t necessarily the same. Focus on the popular parts and perhaps postpone elements that don’t help your customers. Convince business stakeholders using numbers, customer feedback, and research.

In practical terms:

• Gather the latest site map and content inventory information—reports or the previous spreadsheets.
• Find or get in touch with whoever owns analytics (“hey, is this page popular?”).
• Add this to an outline of the FDD or whatever document manages your deliverables (work breakdown structure, Gantt chart, or agile board).

In the end, the advice was simple if not necessarily easy: prioritize according to your strategy. The hard part now is that I'll have to take my own advice for a change. ;-)

Hello from Amsterdam!

It's official. I've joined SDL Product Management and moved the family and dogs to Holland (well, the Netherlands really, but see this video to grok the difference*).

Here's a quick recap of my first month here and what's next.

Week 1: Arrival

Arriving mid-week on the 2 September, I had three days of paperwork and applications. The order was roughly:

1. HR and IT orientations at work
2. Register with the city and complete immigration at the Expat center
3. Get a bank account

Big thanks to the colleagues that helped us get over, from flights to passport information to tips and advice on Dutch culture, food, and where to live. Maybe a very helpful person in HR may start a blog someday. ;-)

Week 2: Presentation Preparation

I prepared for workshops for the SDL Open House, continued working on blog posts about SDL Web 8, finished an introductory slide deck, and prepped for the Tridion Developer Summit.

I also got acquainted with the team and started attending Product-related meetings, which have a different feel than client meetings and workshops.

Week 3: Open House. Open Community.

Last week was all about the open house and Tridion Developer Summit. Great job to the presenters, attendees, and especially Robert Curlette for braving a second year.

I particularly liked the impromptu session where you provided ideas for extensions, which I'm asking participants to list on Tridion StackExchange Meta.

Week 4: Connections

This past week I posted part 2 of our series on SDL Web 8. If the posts sound bigger and look nicer than what I usually post it's because they are. My boss asked me to work with my colleagues and even let me use our official materials as input into parts 1 and 2.

I've also had a chance to meet even more colleagues, answer questions, research, philosophize, and conduct other Product Manager-related activities.

What's next? I'm next working to clarify my role in the "new" team**. We'll spend time looking at what SDL Web 8 includes and what we should focus on in SDL Web 9. So if I ping you with a question or to introduce you to someone that has a question, please respond like I invented the Midas Rule (I did). And by the Midas Rule, you'll probably want to get your feedback in for the next release. ;-)

**Bart Koopman and I were introduced to the team as the new old guys, considering we have roughly two decades of Tridion experience between us and our combined ages make us 80 years old.

*Oh and if you think the Holland vs. Netherlands video was confusing, see another video from CGP Grey on the United States.

That Should be in the Product!

Alex Klock, of Razor Mediator fame, presented his work on Content Bloom's Alchemy GUI extension framework at this year's SDL Tridion Community Award (MVP) retreat (2014 video). As the community releases, and even re-releases, SDL Web (Tridion) extensions, some might ask, "why isn't that already in the product?"

There are a lot of business decisions from legacy requirements, to market desires, to customer needs, to an entire development process that drive what's actually in the box. I can't speak for what's in Tridion today (maybe tomorrow), but I respect the history (and love the product!).

But since I'm joining the Product Management, making it fair game to ask, let's explore some ways to evaluate product suggestions by looking at BluePrinting and Content Management System (CMS) development.

The following diagram has a Y-axis for Publications (roughly SDL Web-managed sites) and an X-axis for CMS environments. DTAP refers to the CMS environments of Dev, Test, Acceptance, and Production. Combining the varations give us this table and a graphic:

Publication (site) variation	DTAP variation	Example
Different per publication	Different per CMS environment	Site system settings
Different per publication	Same across CMS environments	Language Codes
Same across publications	Different per CMS environment	CMS Instance configuration
Same across publication	Same across CMS environments	Organization-specific settings

Notice a few patterns in this matrix:

• Content manager, "single source," and some developer-related settings tend to be the same across environments. Building blocks like Schemas, Component Templates, and Components for headers and footers are also consistent across the DTAP environments.
• Delivery-side configuration varies between sites or Publications, though many need values for Language Code or Site URL.
• Settings that vary across both DTAP and Publications start to multiply. It might help to have easier ways to manage the delivery-side topology of a given DTAP environment (that's a hint).

Plotting various managed elements, including configuration in Tridion Component or Metadata, creates a snapshot of a given organization. Add a Z-axis to represent different customers and you can evaluate when something applies universally, in which contexts.

For example, if all customers used certain Publication Metadata fields with the same options (e.g. language codes in the format of xx-YY where xx is language and YY is Country/Region) across all their environments, it would make sense to add "language code" as a Publication product feature, rather than an implementation option.

Before wanting something in the product, you want to be aware of how it will function across websites and DTAP environments. Adding additional dimensions such as "type of user" or "size of implementation" can further help analyze a request for "productization."

For a given Alchemy 4 Tridion module (or any extended SDL Web functionality), considering who needs what functionality and where (in which publications/environments) helps address "why something isn't in the product" and maybe even "when" something will be. Even knowing all of this still leaves the interesting question of if we should put something in the product (and even who's the right people to build some functionality, but that's a different post).

With the "coding" part of the retreat done, I want to say thank you to Alex, Content Bloom, and the SDL Web MVP participants. Community contributions (and use) can highlight what features are important to you, your colleagues, and customers. I've been a fan since I joined the community and will continue to support your efforts in whatever role I play.

Everyone else, have your GUI extension developers or consultants check out Alchemy 4 Tridion as Alex and Content Bloom introduce this framework to the community!