In business we constantly design. Design thinking is more than products, goods, or service design. Design surrounds us: meeting design, strategy design, communication design, training design, and project and program design succeeds when objectives are met. Here are four persona design tools that align to user objectives.
Effective design can borrow quality tools from other professions and, with context, design for impact.
Some design efforts, such as strategy, business process re-engineering, or talent engagement initiatives, may result in new processes, new standards, or new tasks, but the design goal remains: adoption and utility.
Adoption starts with understanding. Utility then maximizes adoption potential. An example of poor utility: driving a Ferrari only in a city does not really get full utility of the design intent.
The goal of design remains a change, the better goal is measurable and/or observable a couple of ways:
- The outcome: did the design have the impact intended?
- The resource: was the design worth the investment, time or resources?
When we have to plan a meeting and design an agenda, what’s the point? The point is to change behavior or cause a reaction. When we design emails or town halls or websites our goal is stakeholder impact or level of end-user adoption.
From large to small, from far away launch dates to just-around-the-corner, design is critical to conceive a solution(s), convey a vision, and motivate action. Any one, or combination of, the following three things should guide your design:
- Awareness – sharing the context
- Adoption – owning the outcome
- Utility – maximizing the potential
Quality Persona Design Tools in Context
Effective design, meaning end-user adoption and utility, relies on 4 design quality assurance tools:
- Principles – broad ideas, as well as rules and hints about how to best use idioms
- Patterns – the patterns within, figures of speech, acronyms, vernacular common to meet and address requirements and concerns specific to your persona
- Process – description of how to go about understanding requirements and how to then translate those requirements into the frameworks and the interaction to develop how best to apply principles and patterns to specific contexts*
- Promise – the boundary of what you set out to solve, improve, or make better
Too many times only one may take an extraordinary focus at the cost of the other three. In my experience, the 1 that most often suppresses the others is process (governance). When process is perfect, but promise missed anyone who claims success is delusional.
Further, too often, the designer does not think of all four as quality tools needed to guide their implementation model. An example that comes to mind, painfully too often, is the reliance on process more than principle.
Intentional design needs the four to systematically build for the end-user solution. Fragmented or divorced from each the design rarely achieves, let alone sustains, end-user an adoption and utility.
An example: design that relies heavily on process without principles, patterns, or promise might be a workflow process. Communicating a workflow process may answer the what, but rarely encompasses the full impact of why.
Principles, patterns, process, promise also are not relevant to all stakeholders. Their relevance is in context to the stakeholder community, group, or team tasks accomplish, an example from About Face 3: the producer of the style guide and the consumer/practitioner of style have different needs.
How does a process or a style guide fit the consumer/practitioner’s context or need?
An example of the four working in concert is an enterprise software roll out strategy with principles, patterns, process, and promise to guide quality criteria needed to meet audience or persona context for their work environment. Think about an enterprise, software, package rollout from two simple personas:
- Enterprise software rollout quality standards in context of Information Technology?
- Enterprise software rollout quality standards in context of business or end-user experience?
The two should never compete against each other, but the reality is that the measure of success for each persona is not shared. And that is OK as long as the divergent goals are accounted for.
With another take on an enterprise software roll out example, the two groups have design principles that are mutually exclusive from each other’s context:
- IT: A software expert’s design context on all that can be accomplished with this software
- End-user: design from the context of all the tasks my boss expects should be accomplished
Context is King
Keeping your target persona in mind at the beginning of any design means you understand their motivations. Understanding their motivations means you ar aware of their needs. When you have their needs in mind you can meet their goals. This means you have their context as a guide.
Measuring and monitoring against your design quality tools throughout provides a road test for the end-user experience. This makes for more successful adoption and utility as it meets their need.
Throughout design make sure no one of the design qualities, Principles, Patterns, Process, or Promise carries too much weight. Too much weight thrown on one will skew the design. This provides good guidance to any stakeholders that may care more about process than the end-user experience.
Without the design qualities or the persona context in mind you’ve left out the intention to design in the first place: opportunity. There is a huge difference between getting it done: the style guide is finished to getting it accomplished: 95% of enterprise SharePoint sites never used the style guide.
Intentional design, from the start, whether organization development, change management, or quality improvement methods should integrate principles, processes, patterns, and promise. These four keep end-user context, meaning both adoption and utility, as a justification for the business investment. Design standards provide measurable adoption, utility, and return on involvement goals that justify the investment.
To leverage thoughts from the persona blog series: an organization develops when people develop. Design that conveys one thing to no one is a waste of time. Community persona strategies leverage these design tools that kindle individual and community intrinsic motivation.
Organization development is relevant to the business only when organization development shows it gets business. Why are community persona and why are design tools relevent:
- Persona perspective provides the foundation for community
- Design affects human behavior within community
A paycheck is a contract. A community is a commitment.
*the first three presented by Cooper, Reimann, and Cronin in About Face 3 The Essentials of Interaction Design, the fourth: promise, I added to remind ourselves that how we deliver is less important than the promise of what we said we would deliver.
Community Persona Design for Organizations
- Buyer persona for organization strategy and development
- Community persona for organization development
- 4 design tools to meet persona context
- Community persona resource and influence timeline
- Communication with goal-oriented design and community persona strategy
- Community persona for SharePoint intranet design
- Community persona reaction for functional design
- Community persona for change management
- Community persona for project management
Share this Post
I like the language of this piece. It bridges the domains of BPM, Information Architecture and Enterprise Architecture. We all need to be talking off the same sheet.
Funny how parochial we get in terms we use, acronyms in profession or industry, and how we have a go-to set of tools or processes that become part of the working artifacts.
We become myopic by the professional clans and cultures we are around. Certainly consulting has their own codes and terms that, if not careful, really turn clients off. Consultant-speak, just as accountant-speak, or IT-speak may not translate to local language of people across the business trying to get things done.
When challenged by the St. Louis OD Network to design a presentation for the shifting role of OD in business, I really plunged into the persona work in technology, industrial design, and other fields. Fascinating that the goal was the same: understand the motivations and problems from the user perspective.
You bring up a valid point of how to speak of the same sheet. I’ve often resorted to starting meetings or facilitations with baseline definitions. Some get aggravated that this definition refresh is a waste of time, but people use terms differently even if they are in the same field. Starting on the same sheet mitigates assumptions and ego of people too afraid to admit they do not know what PNG means.
So, would we need a United Nations of Business to get us on the same page?
I recommend we hit the buffet line together. Here are 4 I am drawn to for the community persona series I am working all links are to their blogs:
Adele Revella – marketing and public relations
Alan Cooper – software
David Meerman Scott – marketing and public relations
Lene Nielsen – user interface
Who are some you think I could expand my awareness with?