Experience Design

Experience design is really about telling the user's story to business so that it can be addressed and curated along the entire customer experience (CX). It's also about telling the business's story or the market story, known or unknown, to the user audience. I must understand their stories in their own words, terms, and of course experiences, not only in their job interaction or definition of products or services, but their life - goals, aspirations, and desires as well (User-Centered Design). For the business this typically manifests as the "road map" among other driving principles. I then construct a story to communicate a new or improved product or service that can be embraced by the users and their respective companies. I express this story in drawn, written, and verbal form (especially collaborative) based on how best to communicate the story. My strong visual sense and ability to communicate addresses a rich canvas of user and market needs from which to evolve new or existing products and services. This is ultimately the UX Design portion of Experience Design, and it is informed by comprehensive and meaningful research that stands up foundationally under the tenets of Design Operations (DesignOps) with well-thought-out strategies (UX Strategy).


Enter Design Operations (DesignOps). Creating and curating designs, design research, and objectives, as well as how we are going to manifest and deliver assets, and who is going to work on projects involves orchestration and optimization on many different fronts, including who, why, when, and how. DesignOps, to me, at an integral level is about people - internal, external - holistic; and when mirrored in business, omnichannel UX. DesignOps tackles opportunities and challenges from a strategy perspective, from creating or enhancing a design ecosystem of standardized processes, methods, and tools to implementing efficient workflows as well as the quality and impact of those designs. It's also about growing and evolving design teams rich with individuals who have the right skills. As a DesignOps leader it's my job to understand not only the right fit for the role or project, but also the desires and passions of the individual. For example, you'd be surprised how fast you can enhance a vocation with avocational attributes or willingness and intuition to produce even greater results than just analyzing someone's flat skill set and past accomplishments. That is the careful balancing of the DesignOps Role and the DesignOps Mindset in supporting designers, leveraging collaboration, optimizing and prioritizing for success, and measuring and celebrating success (ceremony and ritual). Enable your teams as well as your customers.

Manifesting the Who? of your User Audience

Since it's impossible and time consuming to relate all user profile information, it's often best to develop personas that business and engineering can address during the story to understand succint ideas to address. Tasks and goals are an important structure to the story. This all helps to relate the user scenarios and focus on important business goals toward success of the product or service and confidence and joy for the user audience.


What is it? A persona is a fictional person that represents a makjor user group of defined profiles. These are created by working with Subject Matter Experts and end-users to build characteristics that are most representative of those groups.

What are the benefits?

  • Helps the team focus on the users' goals and needs.
  • The team can concentrate on designing a manageable set of personas knowing they represent the needs of many users.
  • By asking, "Would Tom the Manager use this?" the team focuses on what the user actually needs or uses.

I am responsible for understanding and maintaing business context, membership, and entitlement makup of business functions (title, location, project, etc.) that business roles map to. In that way I and project management, engineering, and other stake holders help to balance business needs with user needs through user and task analysis.



What is it? A goal is an end-condition, not to be confused with a task, which is an intermediate process required to achieve a goal.

What are the differences between goals and tasks from the goal perspective?

  • Tasks change as technology changes. Goals remain consistently stable.
  • The most important goal is for a user to retain their dignity; basically, not feel stupid.
  • Designing from the standpoint of tasks is the main cause of user frustration and non-intuitive interaction.

Desiging scenarios, commonly known as User Flows, from a goal-oriented perspective allows me to tell a story that envisions confident, joyful, intuitive interaction.



What is it? A set of illustrations (wireframes, mockups, prototypes) displayed in connected sequence to convey a user's intended journey through the system, pre-visualizing the interactive experience.

What are the differences between goals and tasks from the scenario perspective?

  • Product owners can visualize how to meet business goals.
  • User can validate the process flow in the application.
  • Product and project managers can see the information users need in order to complete tasks.
  • Quality Assurance can easily compare "as-built" to "as-designed".

©2022 OakenDoor. All rights reserved. No copying or sharing.