Amongst the pieces of things this initiative has made evident, one of which has been a misunderstanding and misapplication of what it means to do, leverage, or even understand user experience (UX). For some, UX means the visual aesthetic- the user interface of a website, and not even the interactions, but just its colors, layout, and branding. For some, their landing of user experience begins at interviews and design thinking games, and ends at reports with tangible assets to hand off to someone else to implement so that the interviews and games could be restarted anew. Regardless, of these and other approaches, it is just a problem.

However that may be, setting out to course correct postures and perspectives is like having a third vocation. The evangelism to those who pigeon-hole artifacts and practitioners is one layer. The offering to celebrity and framework pins another layer - which feels as if it is some kind of pinnacle for some. And then there’s this reconciliation to a golden rule for another layer - where the practitioner and experience design unknot from themselves into a thematic “reason” or “weighty acknowledgement.” Strange as it may be, people and companies alike traverse these levels, most finding themselves sticking closely to one layer, looking with love and disdain to the others. What if that were allowed to be normal?

In one of the ventures, we have an opportunity to set the course for user experience onto a more solid foundation. One where the company can matriculate through layers of design maturity, while the practice finds and develops itself in a shape not-to-different from the theological analogy just mentioned. Such a shape destines one for a route of patience and penalty. And yet, there’s something correct about “working out one’s footsteps of faith” while helping others discover how to view their own.

An initial grasp at this was to shift the term for the practitioner from user experience designer to user experience solutions architect. Going this route gave for a crow-bar to the widening of the posture and methods UX has already been accustomed to leveraging. Generally, a solutions architect is regarded as an engineering-derived role. One where data, process, and business outcomes are modeled towards attributes known by and tracked by the business (client) and their audiences (customers). These attributes also happen to be granted within the contexts of the known and discoverable technologies which can be built to execute that solution. The solution architect isn’t concerned with quality, but they are concerned with the quality which comes from the solution they’ve modeled. Therefore, ascribing this to the user experience lens didn’t just make sense, it invited reflection as to why this had not been done previously.

From here, we settled into our framework for defining design (design, code, context, research, and strategy), and its value-based rubric. This enabled some fine-tuning of what is and isn’t known about the strengths and weaknesses of UX practitioners, while aligning their methods to deliverables in a remarkably approachable manner. Plotting these on a scale per project, program, and organizational outcome enables something similar to a gap analysis (from one lens) and a shaping of what it will mean to solution better experiences (from another). Avanceé has used this framework for sensemaking and analysis purposes for sometime - it works quite well.

Regular monitoring of practice and practitioner commences from here, and then we can begin using artifacts such as a heuristic evaluation to determine just how close a product or process is getting to meeting the expections persons might have for experiencing the delivered artifact. This leveraging of quantitative data is necessary - design rarely comes across as anything more than subjective or “what can I see.” Driving those outputs into outcome-lenses helps to keep the UX practitioner away from unnecessary work, and can play the role of “tradable asset” to programs which might ascribe to Agile (and similar) project management practices. The disadvantage of these analysis tools will be a widening of perspective to the politics and devaluing of outcome-driven approaches by many projects or project participants. Many folks lose or gain religion here.

Ultimately, the execution of what has been discovered, measured, and tested will be evaluated by the audience (client) which must utilize the thing. Experience is subjective. And therefore liking it or not liking it will be a part of the acceptance of the approach. The UX solution architect is postured well for this because of the tenant which undergirds this framing - they solution towards boundaries of acceptance, they are not responsible for acceptance. This is the last layer many find it difficult to get to - user experience isn’t acceptance, its governance to what will be accepted.

If this diatribe holds, then we might be able to give a slightly better definition of user experience and its practitioners, and embue all parties with a sense of the execution which needs to matter to whom. Here’s where a shape of this definition stands at the time of writing

{company or UX-SA} integrates mature and ethical products which navigate diverse permutations of use and tasking; understanding engineering as “implemented architecture”. This is core to solution architects as well as humane design practitioners. Through architecting the software to be implemented, then measuring its success via user input, we realize the engineered outcomes and assess for fit, friction, and fiscal responsibility. To the UX Solution Architect, “defects” come via user insights and quality assurance (QA), not from running a debug script. These defects are then classisfied as operational, transactional, and/or process based and measured against industry, psychological, and/or organizational metrics. The clear and communicative execution of this governance resolves to trusted, performant, secure, and accomplished products and services for its intended audiences and the sponsoring business units.

This feels like the right spot to take this. Does it encompass all? Nope. Is there room to debate the attribution to engineering? Yep. All of that and more should be the case for widening the perception of what user experience actually means and does. And from here, that which we believe (or not) about manipulating people and products for some purpose shows itself in what we all might be accountable to, or end up bearing the burden of.