In order to architect successful experiences within the user-solution engagement I establish frameworks by recognizing contextual patterns and gathering functional requirements to be utilized both in development and consumption agile cycles.

By generating value through experience architecture I not only strive to define and build engaging interactions and also ensure sustainability of the solution within your organizational processes.

Inception of the experience, and therefore of the solution, is crucial in that it provides a map to which we adhere to in order to mitigate arguments and support our decisions, as well as to ensure that the product owners, development teams as well as users share common goals.

Context is relevancy

As much as we hate to admit it, or at least fail to realize, users do exists prior to and after interacting with our solutions. Which is why observing the context in which the engagement is framed as well as intent of defined target audiences allows us to recognize their needs. Needs which we address, problems our solutions solve, or tasks we can enable users to complete must be defined by building experiences which fit into lives of users we are creating for.

It is important to recognize the different types of environments and channels in which users engage, different devices they use to do so, and ultimately the story which is told by experiencing our solutions in different contexts.
Through conducting contextual user research, gathering feedback with heuristic evaluations and gauging acceptance we are enabled to define, build and optimize natural and intuitive experiences.

Encompassing Experience Architecture

Steve Jobs said “Design is the product”. For what it’s worth, I’d like to rebuttal that with “Experience is the solution”. Elaborating on the brief context manifesto provided above, my argument is that every experience decision made must be traced to a supporting objective, making user experience the true measurement of success according to what stage of the user’s journey it supports.

Example of a conversion process in an experience architecture funnel

However, in my experience, once goals (what we are trying to achieve) are set, their inertia grows exponentially, so much that we rush to achieve them and in doing so overlook the principles (how we will achieve these goals) as well as patterns (what we will create to support them) of the experience.

Discovering principles

In order to apply design and experience principles we must first appraise the needs of target audiences against the stated goals and established strategies for achieving the same.

For instance, if a solution foresees a need for pivoting its strategy in the near future as you’re appraising viability, principles which will best support such a goal would be adaptable ones such as modularity and embeddability which function via the means of flexible design patterns and designing elements rather than layouts so that you may quickly reorganize, and recycle.

You may address scalability, tracking, etc. of your goals in the same way. Establishing principles allows the solution to incorporate considerations for everything from presentation layer organization to allocating resources for maintenance.

Deriving patterns

Principles are used to extrapolate patterns which may range from sets of interactions structured to maximize accessibility and usefulness of solutions, to interface specifications which ensure consistency in user solution interaction cycles. Patterns are meant to be replicated and reused; that is their purpose. This is not only efficient but it also reinforces set objectives with each use when aligned properly with expectations.

For example, modularity established as a principle becomes well suited for flexible goals resulting in patterns such as form agnostic content, allowing elements of experience to be re-positioned and revalued, tested etc.

Business process value

Success of the solution not only depends on quality of the experience users interacting with it have, but also on it’s capacities as a business tool. Allowing for flexibility to test assumptions and consequently pivot objectives efficiently and effectively is one of the prime considerations I make.

Knowing who will be maintaining the solution, who will be updating its content etc. allows for positioning the solution architecture in such a way as to provide seamless integration and further optimization of your business development processes.

My background provides me with deep understanding of organizational objectives, unique team structures and development methodologies as well as other considerations and strategies for implementing the solutions in them, varying from writing training documentation to modeling real time data exchanges.