Daniel Brent Patton

Product Content Strategy & UX Writing

My Process

I began my career as a technical writer, mapped to IT, Product, and Technology Project teams. The content I developed and managed targeted more technical enterprise users, rather than customer-buyers.

I developed manuals, online help, user support materials, and interface copy. Where there were opportunities to single-source—to have the same content modules or chunks appear in multiple places for different purposes—I grew to appreciate those planning and engineering aspects as much as the conventional writing tasks.

I’ve since worked with Marketing and Sales organizations, both directly and cross-functionally, and have grown digital marketing and complex sales skills sets. And while I’m comfortable nowadays developing for the consumer-buyer, I still love the enterprise user and I take great personal satisfaction in making their lives a little easier.

Enterprise UX

While I take a user-centered approach to every project, process always varies based on type, business or technical constraints, objectives, budget, and timeline. In Enterprise UX assignments especially, I often work with project managers or leadership to fold as many Discover-Define-Develop-Deliver iterations as possible into any larger methodology at play.

I try to adhere to the Double Diamond UX model whenever possible and map appropriate phased deliverables to it. Often, however, I’m working with distributed cross-functional teams in a corporate environment at varying levels of UX maturity and so must adhere to the model I’m presented with.

In those cases, I will work with a project manager or business analyst to account for the periods of divergent thinking required to uncover the optimal ideas traditionally found in the Discover and Develop phases.

As UX principles and methods continue to infiltrate the enterprise—beyond product teams and into employee experience and internal applications—I’m finding less and less pushback to contextual inquiry, usability testing, and routinized iteration.

I define Enterprise UX generally as work done for internal employee-facing sites—intranets and portals, productivity tools, content management systems, highly-configurable enterprise software, or custom applications—rather than those directed towards a company’s customers.

An Enterprise UX project is often differentiated from an e-commerce site, brand presence, marketing campaign, or customer-facing app in terms of the budgets, skillsets, and timelines the organization will dedicate to it.

So, I’m sure to include thoughtful approaches to ROI measurement into my process as well, to reinforce the ongoing level of commitment required from stakeholders throughout the project lifecycle. If I can quantify the benefits of good design in terms of reduced operational cost, improved compliance, or growing employee satisfaction and tenure, then everyone can better support the time spent with users up-front.

Regardless of the type of UX work I’m doing, I strive to collaborate well with creative teams, stakeholders, and users, and to respect the iterative end-to-end process that drives the most effective solutions.

My Principles

Start with Business Strategy: Roll up every material design decision to a business goal.

Support Users’ Mental Models: Start from the shared metaphor for beliefs, attitudes, and behaviors—and not from your own notions in isolation.

Structure-First is Content-First: Focus on defining and engineering content types, then use object-oriented UX principles to map them together into screens and flows that make sense and save design iterations.

Iterate Often, Fail Fast: Crave feedback and dig down to the authentic insights. Changing paper is cheaper than changing code.

Minimize Technical Debt: Bring data to support relentless user-focus in the face of pressure to ship.

Love the Writer: Theirs is among the most difficult jobs in this world.

Content Strategy

The term has come to mean different things to different people, based on their own experiences, functional roles, and the environments in which they work. The bulk of my experience has been in operational content strategy—what Ann Rockley calls “Back-End” strategy—and this is as much a product of my own functional roles as anything else.

Unfortunately, today some still view content development (or migration) as an afterthought—like pouring liquid into a mold. As a key determining factor in my creative process, I view Content Strategy as a clear point of reference for most downstream design decisions.

In my content strategy work, I apply Discover-Define-Develop-Deliver not only to the solution design, but to the author experience as well. After all, it is those individuals charged with content production and maintenance that will differentiate the site’s positioning as either an evolving credible information source or a stale decorative artifact.

Information Architecture

When asked my positions on Content Strategy and Information Architecture, I find myself returning to the “two sides of the same coin” analogy as described by Morville and Rosenfeld in the polar bear book.

If Content Strategy is the temporal view of information flowing through digital environments, then Information Architecture is the spatial view—hierarchy, structure, and design in service of discoverability, findability, and usability. And while in practice the functions can overlap, I find the two-sided coin analogy helpful in articulating requirements, process and deliverables for teammates and stakeholders further upstream or downstream in my process.

For new projects, I like to build and socialize domain models that lay out visually the entities and relationships (often nouns and verb phrases) that describe the information space users will be working in.

This exercise is especially helpful on lean projects, or those employing an object-oriented UX process. Not only does the model feed directly into feature prioritization and wireframing, but object-orientation can be a comforting frame for credibility-building with developers or technical stakeholders.

Artifacts & Deliverables

While processes change based on project specifics, the following are representative artifacts and exercises produced in the course of my work.

Discover

Affinity Diagrams
Analytics Reports
Author Interviews
Card Sorts
Competitive Analyses
Content Inventories
Contextual Inquiry
Organizational Needs Surveys
Problem Definitions
Stakeholder Interviews
User Interviews
User/Customer Experience Assessments

Define

Card Sort Analyses
Classification Schemes
Conceptual Sitemaps
Content Audits
Content Migration Plans
Roadmaps
Governance Models
Personas
Prioritization Matrixes
Taxonomies
User Flows
User/Customer Journeys

Develop

Content Life Cycles
Content Matrixes
Content Models
Content Types
Editorial Calendars
Localization and Translation Plans
Metadata Strategies
Prototypes
SEO Recommendations
Style Guides
Usability Test Analyses
Wireframes