Some companies take a quite structured approach to creating user experiences. Others create user experiences unwittingly. Looking back, I detected six principles in regards to creating user experiences.

Every company has a specific situation and evolves a characteristic structure. Nevertheless, creating great user experiences follows some common principles. So one would expect to find similar patterns on how companies adopt a user-centered approach.

This article sets a focus on the following patterns:

• Those who drive the user experience
• The need to slow down
• Direct feedback loop
• Interdisciplinary teams and continuous discovery
• UX enablers
• Knowledge flow

And concludes with some remarks about the requirements for an organisation to be more user centered, how to become more agile as UX professionals, and the long sought for silver bullet.

Those who drive user experiences

Public Transport: When setting up a project (about 15 team members) as part of a bigger program (about 80 people), the program leader staffed a UX architect and an interaction designer into the team and recruited expert users who participated in the project two days a week. The UX architect had the role of a product owner. The expert users used their network so the team gained easy and quick access to more users for exploration and testing.

Financial services: The product owner, with help from a domain expert, worked out a functional specification as wire frames, handed this over to a visual designer who created high fidelity mock-ups and aligned it with the design system. This then was passed on to developers to build. Other UX activities did not get enough time and getting access to users was close to impossible.

Industrial machinery: A product manager responsible for heavy duty industrial machinery started the product development with a series of workshops to get the user experience right and made sure the team had access to users to test ideas, prototypes and the product under development.

The three examples above differ especially in the UX brief. And this brief stems first from the business driver behind the project and second from what those in charge of the product assume is the value of a great user experiences.

Example	Public transport	Financial services	Industrial machinery
Business drivers	Better service to travelers by better communication	Get to the market quickly	Increase sales
Perceived UX value	A usable product makes employees more effective	Great colors, nice icons and minimal number of clicks sells.	Make the customer’s business case work by reducing set-up time
UX brief	The software should make employees communicate more effectively	The product should look great	Make it efficient to set-up a new job.

So it should come with no surprise that in the financial services example some designer colored the pixels and optimized clicks and that all the rest of UX work, like defining the target audience, scoping the system, prioritizing features, defining work flows of the users, or designing the screen flows in the software, was left to the intuition of the product owner and to chance.

In two other development examples, those in charge of the products were able to connect the value proposition of UX with making business and then acted accordingly.

One thing stands out to me: how those in charge of the product or the project connect UX with business goals makes the difference. They make key decisions, set priorities, staff team members and are quite often key to gain access to users. If their perception of the value of UX points into the wrong direction, it is very hard for the others to change it. In many companies today, these persons decide the fate of a product’s user experience.

Whatever the situation, when key decisions are made around the product, the user experience needs to be taken into account and it must be connected with the business goals. There are different approaches to achieve this:

• The decision maker is also skilled in UX and has done the homework.
• The decision maker has trusted UX professionals who did the homework and relies on their judgement.
• A team makes the decision after having made the homework.

The scaled agile framework (SAFe) has introduced an interesting approach by paring the product leads with technical leads. Why not add UX professionals where needed?

Having the right skills and knowledge at the right time can only happen, if enough time is available. That is why some organization must slow down to gain speed.

The need to slow down

Real estate: The company had to replace their core system which directly affected probably half of the employees. At the same time, several other projects of similar size were started, on top of daily business. All competed for the same, limited resources. As the heads of the different project had equal strength, all of the projects kept going with rather mediocre speed and quality of results.

Retail: Objectives for the department heads were defined reflecting their departments contribution to overall company goals. Some had an incentive to increase the conversion rate in the online shop, others to open up new fields of business, to overhaul the software tools and more. Quite obviously, the more powerful persons won most of the battles. None of the powerful lords hat the goal to create a great user experience.

Online shop: The company installed a kanban board on top management level. This kanban board did two amazing things: It created awareness about the cost and state of the initiatives and it limited the amount of initiatives. It even granted room for product owners and engineers to maintain and improve the current systems.

Companies, in general, try to do too much and press on time-to-market. When pressed, most people skip crucial steps, accept unnecessary risks – and become slower. They achieve less with lower quality.

Agile and user-centered principles can help:

• Interact with customers and users to know the real value and where to set priorities.
• Only do the most valuable things.
• Accept that things take more time than one would hope for.
• Invest into the search of the relevant problem and a simple, competitive solution rather than building many features (see featuritis).
• Build a culture of trust between management and employees.

Setting priorities happens on multiple levels within an organization. For simplicity, lets reduce it to the levels customers and users (compare with customers, users or fans). The case of a relevant UX problem is an example of how the two levels can relate to each other.

On the customer level: The big initiatives and the strategic decisions usually center about customers, the markets, the value propositions. How do we best do business with our customers. Here, management and product management meet. In order to assign appropriate priorities, customers need to be involved. You want to hit a relevant customer need with a competitive solution and you want to spread the word.

On the user level: When it comes to work out the concrete product or service, the decisions base more on insights gathered from users. This is where product management and development meets. To assign appropriate priorities users need to be involved. You want to create a desirable change in users life with the available resources and to start the change – while keeping the promise made to customers, of course.

The tools of choice nowadays for prioritization are backlogs, kanban boards and the likes. These tools will be at different levels of the company, at the top to prioritize the big initiatives as well as on the bottom, do coordinate the daily tasks.

All of these tools have one similar strength: They limit the number of things to do at the same time.

Next, to find the priorities, a feedback loop with customers and users is mandatory. How else can you know whether you products will strike a chord with them?

Direct feedback loop

Online Shop: A company has a dedicated user research and testing team. The great thing, they have easy access to users and can create a representative sample. The not so good thing: It takes four weeks at least to do a study. The result is a report. Generally, after a quick glance over the most important findings the product owner files the report in the project repository. The teams resort to hallway testing where they can have feedback within two days and can discuss immediately how to improve it.

Secure patient data: The usability test was done by the UX professionals with the project leader and the developers as observers. Together, the team consolidated the findings and decided on what to change.

Hearing aids: The UX researcher created a prototyping platform where they could simulate typical and difficult hearing situations. Test users could then experience how different prototypes helped to master these situations.

Literature documents many options on how to evaluate a product with customers and users. The gist of it: teams need a fast and effective feedback loop. The key is not to just ask what people think about a product, but to sketch the future world, let them experience this world and conclude from this experiment.

The focus of such a feedback loop changes while an idea is maturing from stars to road (see meet with users to create great products). A few of the many great techniques people developed are outlined in the user experience flow from stars to road.

Surprisingly, the obstacle is usually not missing knowledge about user centered methodology, but getting to those who can give feedback.

Here are some approaches I find more helpful, at least in some situations, to gain access to users.

• Go one floor up: Very fast, great feedback. Works best for internal software where the users work one floor up. Otherwise, expect blind spots.
• Make the team users: Very fast, many blind spots, but at least the team members put on the users’ shoes and try to walk with them. This can completely change their perspective.
• Family and friends: Can work, don’t forget NDAs and data protection policies. Mixes professional and private live.
• Employ agency: Takes a bit time to setup, more no shows than you like and you must double check the profile match.
• Add users to team: Use their network into the company. Quite fast, few blind spots, great for professional software in a large organization.
• Key customers: Talk to users from key customers. Needs a contract, then quite fast, a bit of a blind spot, great for professional products.
• Street show: Setup something eye catching on the street and engage those walking by. Quite quick to setup, some blind spots due to the locality and whom you can engage, can work very well for consumer products.
• Engage community: Fast once you have the active community, needs a large user base, some fans and an existing product.
• Go the long way: Via product management, to marketing, to local distributers, to customers and gain access to users that way. Slow, but you get real users across the world. Throw out hooks to create your project related user pool.
• Company user pool: Takes some money to setup and run, then its quite fast, needs an internal agency to maintain the pool.

I think you get the challenge: the more numerous and wide-spread the target audience, the more creating some kind of a pool or even community of users is helpful. This however needs an investment.

It is a big achievement that many teams nowadays are able to gather feedback from users. The next challenge is to make the feedback flow from users to those who actually need it.

Interdisciplinary teams and continuous discovery

Insurances: For an app for an insurance company the UX architect worked up-front. Together with client and users, he developed a detailed, interactive prototype. This was handed to the development team. The development team, including an interaction designer, struggled to prioritize the many features envisioned so they could stay within budget and basically had to redo the whole thing to accommodate the many details that were overlooked. They were able to keep the fundamental idea behind the prototype, which was great, by the way.

Banking: the so called agile team at a bank was actually an assembly line from innovator to product owner to business analyst to UX architect to visual designer to developers. Everybody added their pieces and bits and if it wouldn’t have been for the struggle of one or two individuals who worked very hard to fit the pieces together, the whole thing would have been a complete failure.

Industrial machinery: In order to develop a new software to configure the machines and setup the jobs, the team started from a UX perspective. They came up with a great concept of how to do it. They then started to build the software. It became a great software, but it was expensive. In hindsight, the product owner concluded that software development should have started much earlier: “I’m quite sure we would have found an easier to build solution that would have worked as well for users”.

Consumer Devices: Product management envisioned a new way for users to interact with their devices. They hired a research company to do some preliminary user research. The researchers filed a report summarizing quantitative findings based on six participants. All the other insights the researchers gathered did not make its way back.

It is is an illusion that the UX professionals are creating the user experience. In fact, product managers and project leaders are those who actually decide the fate of the user experiences. The software architects are the ones who enable UX, domain experts make it working, developers and designers build it. The UX professionals are just the likeliest candidates to envision the users’ experiences.

As everybody is actually working on the user experience and is influencing it through their decisions, all need to know the users. To get to know someone we need to interact with that person. That’s why for me, as a UX professionals, meeting with users is always about connecting.

UX experts build up a lot of knowledge about users, but usually they also create their UX gardens (with sometimes serious consequences, see UX in a burn-out system). They tell everybody not to worry, head off, talk to people, come back with the digest in form of personas, journeys, a design system and detailed hifi mock-ups of the user interface. Problem solved, the others can now just do whatever they are good at. This behavior breaks the flow between users and team. Developers disengage and care for clean code (which is really a good thing to care for) rather than for a great product.

What we need are interdisciplinary teams. Get people with the needed skills, including the so called soft skills, give them a fascinating problem, put them in a room together, remove obstacles so they have easy access to users and other stakeholders and let the magic happen. Nowadays, we call this agile (as outlined in the walkthrough) or design thinking.

Such a team needs something else rather than an assembly line setup, something to reduce personal gardens. Lets call this continuous discovery.

When starting on a new topic, the team sits together, takes the time to work on the problem, the solution, unknowns and risks. It can be a good way to include users and customers in this step already. For investigations, e.g. doing some user research or experimenting with a difficult technical solution, the team probably splits up. Once the investigations are over, the team needs to integrate the different knowledge gained and the next cycle begins.

I would furthermore propose some good UX practices:

• Collective UX ownership: Everybody in the team is responsible for a great user experience and thus discusses UX goals and how to achieve them.
• Pair investigation: UX, PO and devs form pairs to do interviews, context research, testing. The UX professional isn’t even there all the time.
• Mob consolidation: Integrate the results from user research, testing sessions and conclude the impact on the project as a team.
• Team interface design: Do that as a team and use facilitation techniques (see the google design sprint for inspiration) to become more effective.

People will work much more efficiently as soon as they start thinking about interdisciplinary teams. In such a team, UX professionals facilitate the flow between users and team and become UX visionaries, mentors and facilitators. Rather than filling their time with creating high-fidelity mock-ups for developers, UX professionals invest their energy so the other team members connect with users and are able to see the world from a user’s perspective.

Such a change in the job description for UX professionals would also free valuable time these pros could spend on creating shared enablers for great user experiences.

UX enablers

Government: A governmental organization established a design system to ensure that the departments created consistent web-pages to provide their services. The person responsible to get this done resorted to a mixture of threat, blackmail and other psychological violence.

Sports event management: A sports association developed an event management software. The association had their corporate design for print and digital media. Each of the events they organized had it’s own distinct brand with it’s own design system while keeping the corporate brand noticeable. The event management software for those behind the scenes started from the corporate brand and but had its own design system so the professional audience was able to work efficiently.

Retail: A retailer had a design system for the corporate website, another for the real shops and a third for the online shop. The latter is closer to the corporate website than to the real shops. Does it make sense? The different departments still disagree on this.

Companies want to communicate consistent messages to their customers through all channels. As the three examples point out, having the one design system that fits every purpose is not appropriate in many cases. The same is true for user research, personas, journeys, and the usage data collected.

Still, there are common things that are worthwhile to share and to reuse over a wide range of touch points and teams. Examples of such UX enablers are design systems, a repository to share information, common tools for designing and data analytics, a service to gain access to users and more.

But creating the enabler is only the minor part of the job. As the governmental example points out, changing the organization and the people to properly use the enabler is the difficult part. The poor guy in that governmental organization faced the overwhelming challenge of changing hundreds of people who simply did not care for what he wanted them to do.

This is just one of the many drawbacks the obvious organizational solution – i.e. creating a customer or user experience team providing enablers as a service – has. Such a team will work on wonderful enablers and then give them to the development teams. Those teams are however busy getting the promised features ready. Having to deal with the enabler is basically just noise.

If we take a more agile viewpoint and put things back on their feet, it could get much easier.

UX enablers, like other assets as well, consume resources to build them, to adopt them into the daily routine and to maintain them. They are an investment and they belong into the appropriate backlog. Once there, the key persons accept the benefits and costs and agree on the priority. The teams can plan the time to invest and by whom. If needed at all, key persons can drive the change.

Those creating UX enablers are thus part of the development organizations and not of a separate team.

The bigger an organization gets, the more difficult it becomes to get people aligned. People tend to specialize more and more. Disseminating the important knowledge becomes a challenge.

Knowledge flow

Consumer devices: Different product managers create the different products. When user research is done for one device for one product manager, another product manager is bound to specify the other device using the interaction principles user research showed to be the worst to pick.

Hearing Aids: In order to improve interaction with hearing aids, the UX consultant collected the knowledge about known issues, tried solutions from the many stakeholders and integrated this on an interaction map. This allowed product management to define the focus for fundamental user research. Research results where presented mostly with highlight videos and snippets from interviews so that developers and product manager who did not participate in the research could feel their users.

Medical devices: UX researchers studied users and came up with results for new and improved devices. The most important insights were presented to interested parties, mainly product management and senior developers, the rest filed for posterity. The researchers themselves had little involvement in the actual development and thus most of the knowledge the researchers built did not make it to the development department – with sometimes surprising results.

What we call users are just splinters of the real humans a company interacts with. They are an abstraction, a model that serves a purpose, e.g. for creating a specific app or to position a brand.

Most people within a company made their own experiences with users and customers and collected different splinters. These splinters do not line up easily and some even contradict each other. The result, people quarrel about solutions because they have different splinters in mind.

Wouldn’t it be great to have one model for all? With all the splinters integrated into one consistent picture? What sounds like a good plan turns out to be a big a task. The larger an organization gets, the more difficult it gets.

Still, one option seems to work quite decently if the scope is not too big: A high level user view, like user journeys or an interaction map, shows the condensed insights from various sources, like user research, testing, and data analytics. I assume such a user view works if it can be made into a product management tool. It could give an overview over the state of UX to set priorities; serve as entry point to detailed information like analytics results, research reports, test results; and more. Having such a tool certainly helps to gain a shared big picture about the user experience.

Still, for creating great user experiences, many details matter. And communicating such details throughout an organization can prove difficult. Creating documentation, highlight videos and present research results certainly help here.

More promising – besides direct access to users – is to make people collaborate to let knowledge flow. This is when we share knowledge most effectively with each other.

Take the UX research team from the example further up. I think that it is really helpful to have a group of people who can organize participants for tests and user research quickly and reliably and have great methodological knowledge. Does it mean they should run the sessions as well? I’d vote for no. Too much relevant information is lost. My conclusion: they should enable, mentor and support teams in doing it themselves so that knowledge about users flows directly into the teams.

For tasks that cross several teams – e.g. to create UX enablers – an interdisciplinary team can do the bulk of the work. Other than that, forming communities to get to know each other, to spread information and profit from each others insights and difficulties is certainly helpful. And do not underestimate the potential of creating an office environment where people meet each other frequently. Staircases, coffee areas, smoker’s corners are important places for exchange.

For me making information flow through an organization is all about connecting people and teams and make them do something together.

Requirements for a UX organization

A great user experience is not so much the result of UX professionals creating design systems or running tests, it is the result of how those involved connect. In the previous sections I put forward a series of thoughts, you could call them requirements:

#	Strive for this	Ideas on how to do this
1	Include people with UX skills for key decisions like staffing a team, choosing target audience, and setting priorities, so that UX activities take place efficiently.	Spread UX skills, e.g. by education, by consulting, and by promoting UX professionals to key positions.
2	Reduce the things to do on all levels of the company so that teams have time to deliver the needed quality.	Introduce backlogs and agile practices.
3	Do effective feedback loops from stars to road so that teams learn what strikes a chord with customers and users.	Probably needs skilled UX professional to guide teams and deciders.
4	Provide fast and direct ways for teams to talk to users.	In many companies, this is a UX enabler, needs investment and maybe even a dedicated internal or external service.
5	The whole team participates in UX activities and meets with users so decisions are based on a good understanding of users.	Move UX professionals away from assembly line working style to continuous discovery and mentoring.
6	Educate about tools and methods to do UX more effectively.	A community of practice within the company could do the trick.
7	Share insights about users throughout the company so that people align their understanding and decision making gets easier.	Create a user view, set up an environment where people love to meet, and mix and mingle to create UX enablers, products and services.
8	Prioritize and plan UX enablers so the team has resources to do them.	Put enablers in the backlog and treat them as a change project.

Towards an agile and user-centered organization

Insurances: The UX team defines controls and guidelines for development to follow. Teams have difficulty using them. The guidelines and controls do not meet the requirements of the product development teams well.

Retailer: A retailer introduced SAFe for the development department. The UX professionals have been distributed to the teams. They are now fully exposed to the time pressure exerted through the SAFe hierarchy and have little time thinking ahead. Sharing design patterns, doing user research is difficult. The different software applications diverge.

It is generally accepted that caring for a good user experience has a lot of advantages for a company: better position on the market, increased sales, lower costs of training, fewer support cases, warmer recommendations and loads of other benefits. It can even bring quicker time to market in some cases.

Companies thus hire UX professionals to make great user experiences come true. This usually is a big step forward.

The common misconception is, that UX professionals would create a great user experience. This misconception is pushed by us UX professionals ourselves as part of the campaign to sell UX. If you count in that UX professionals have other backgrounds than engineers, and aspire for a different kind of career, then it is probably best to put them into their own team -or should we spread them over the teams?

The approach I think is the most promising one is are interdisciplinary teams formed around larger tasks. People group and regroup depending on the need of the tasks ahead. Obviously there are different kind of tasks around product development:

Purpose	Some details
Development tasks	Develop software products / software based services. Such teams are quite stable for a longer time.
UX enablers	Create UX enabler and run the change needed. Such teams dissolve quickly, once the change is accomplished.
Specialized service	Like providing access to a pool of users, doing data analytics, give UX related training. Quite likely, this is a part time job.
Exchange	Exchange of UX related experience and knowledge. More a community than a team.
Strategic decisions	Set product strategy and discuss priorities. I.e. product management supported by more specialized experts like UX professionals.

While it is important that the individual team members can dedicate their time to the team task, they will also be involved with a more limited time budget in other teams. Some specialists may even be consultants or part-time team members for more than one team at a time.

As far as I know, the most efficient way today to manage something like this are agile frameworks. Three things that I find especially noteworthy about them are:

• Having one common backlog (or more a common system of backlogs) allows to form teams and sub-teams around the tasks at hand and to plan UX enablers.
• A built-in continuous improvement loop allows teams and an organization to adopt UX best practices and newly created UX enablers.
• The top-down approach to setting priorities and the bottom-up approach to estimating and allocating resources can reduce the time pressure and give room to achieve quality.

Just keep in mind: organizations do not become agile by adopting an agile framework. The difference is the mindset of fostering capable and intrinsically motivated teams as opposed to individuals who strive to delineate my job from not my job.

Similarly, a great user experience happens if an organization values and strives for a user-centric mindset as opposed to the an assembly line setup with UX professionals creating high fidelity mock-ups.

The silver bullet

Where is this silver bullet that rids us of the evil of complexity?

After a million of years of human invention, the silver bullet to great products and user experiences is neither a process nor a tool. The silver bullet is still the human brain, i.e. the skilled people, and – as the scaled up version – the super-brain interdisciplinary team.

The purpose of organization seen in this light is

• to connect those who create products with those who use and need products,
• to give them room for creativity and platforms to learn,
• to cultivate an agile and user-centric mind set.

Every company has a specific situation and evolves a characteristic structure. There are more general principles and patterns that will enable a company creating even better user experiences. Which ones are applicable to your company?