In business we constantly design. By design I mean more than just products, goods, or services like cars and software, by design I include that we design meetings, we design strategy, we design communication, we design training, and we design projects and programs as a few items.
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 3 things should guide your design:
- Awareness – sharing the context
- Adoption – owning the outcome
- Utility – maximizing the potential
Quality Design 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 - the 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 1 may take too much focus at the cost of the other 3. In my experience, the 1 that most often suppresses the others is process (governance). When process is perfect, but promise is missed anyone who claims success is delusional.
Further, too often, the designer does not think of all 4 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 4 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 to be accomplished. 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 4 working in concert is an enterprise software rollout 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 2 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 rollout example, the 2 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 4 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 3 presented by Cooper, Reimann, and Cronin in About Face 3 The Essentials of Interaction Design, the 4th, 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