When designing products at large enterprises, final product appearance has to fit multiple purposes. Primary focus is always end user goals. In goal directed design these are represented by Personas and their motivations.
What works in consumer world is just not enough for Enterprise UX. Designing only for end user introduces high risk that final product experience will not meet expectations because of feature creep.
Feature creep
Focusing on end user goals only, enterprises are often introducing feature creep into product design by masking various internal requirements as persona goals. These personas are then becoming elastic and subject of subjective interpretations and personal projections. Its no longer designer who interprets persona motivations and goals found in research into design framework, but large number of stakeholders that are introducing their POVs.
Solution is to deliberately design for internal user too. To make the product successful, all this input coming from internal stakeholder has to be taken into account. But rather than forming design committee and elastic personas, internal stakeholder feedback has to be included in same way as Primary persona's — by formalising their goals and motivations that comes out of relevant research.
Requirements cannot be “gathered” from your stakeholders like Easter eggs — they must be defined, through research and scenarios. Alan Cooper
Internal User
Internal user might perform same tasks as end user, but with vastly different goals and motivations and performing these in different environment.
Goals
Goal of end user is to get the job done — solve the problem that just arises. But for pre-sales consultant using product as part of Proof-of-Concept scenario, his goal starts with figuring out the right problem that will illustrate product capabilities at best. He can do that either by simulating failure to be able to demo alerting capabilities or use mock data.
Typical feature-creeped enterprise product contains too many configuration options. During POC scenarios, consultant has to deploy the product in unknown environments and do that number of times. He is iterating around ideal configuration parameters to find ones that works. But once set, end user barely touches these.
It is valid requirement to make POC experience seamless and reduce risk of errors. The point is that it is not the end user goals that the design is attempting to match, thus end-user cannot be used to validate and test final implementation.
As part of enterprise selling process sales person builds relationships and sell Product vision- Inspiration, Uniqueness, Competitors, Roadmap.
Sales person goal is to explain Product vision directly using product user interface. In enterprise product world this leads to ironic feature naming where features are called similarly to “Cisco Tidal Process Orchestrator”. Goal to squeeze all the product vision into UI labels clearly goes against reducing cognitive load of end users.
It is valid requirement to design product that illustrates overall product vision. But User Interface label is not tool to pass this message. UI labelling should be subject of objective testing such as open card-sorting.
Motivations
End user goal is to solve the problem using whatever tool available. There is no real motivation to use exactly Product A. However for product consultants and support, preference is always to use Product A, even when using Excel to build the same dashboard is much easier than doing it with build in WYSYWIG dashboard editor. Their motivation is to show the value, prove that we can do that too.
Not recognising these as internal requirements and taking them into account as user requirements, final feature rich product will just not solve the problem in simplest possible way.
Environment
Pre-sales consultants with all new travelling gear consisting of MacBook, iPad and Apple Watch are not only presenting their work and collaborating in meeting rooms. Majority of their job is done in meeting rooms. However end user sitting all day in open space cubicle might use the same product in Virtual box window that runs inside another virtualisation service that works only on Internet Explorer 8.
Designing the product for environment we wish end users would live in, instead of their real environment often results in visually beautiful and technologically advanced products that look good in meeting rooms, but are failing to pass the same message in real legacy environments.
Conclusions
Goal directed design can not work in two parallel streams. One where user goals and motivations are transferred into development requirements through proper user research and design framework. Then at various checkpoints they are mixed with internal requirements that are directly formulated by stakeholders, missing the synthesis phase, prioritisationand validation.
Internal requirements bypassing Goal directed design process (c) Cooper
Internal stakeholders goals and motivations should be taken into account, but not by inviting them directly to regular design meetings. That will only result in side-requirements gathering and design committee. Their goals and motivations should be synthesised through user research and crafted into Internal Persona. Their know-how and experience should be then used in validation phases to test design framework assumptions.