Design for Change

The Design phase requires much energy and effort in order to reach the goal of usable products, services, and systems. It sometimes seems as though teams must make all the right decisions or get everything perfect before launch is possible. It's important to remember that no design is permanent; everything will need to change, will have to flex, and will ultimately be succeeded by something that is hopefully more useful and more delightful than the thing originally designed. To prepare for this and to build in space for flexibility and change, many design teams work as though they are always in an iterative loop: constantly designing, testing, delivering, and measuring designs they know aren’t perfect but are getting closer and closer to a perceived ideal. This state can last months or even years, and setting up designs to undergo it is an important part of the design phase process.

8. Wait for the Right Opportunity

As was said before, the design phase is about making decisions. Almost always you will find yourself having to leave behind what you and the team are certain are desirable, feasible design ideas in order to pursue one of those ideas that is more desirable or feasible. This can feel difficult. You might even feel as if you are not fulfilling the needs of your participants, and therefore not fulfilling your project mandate, because you are not meeting all their needs.

Good ideas, based in strong research, however, have a long shelf life. Better than trying to execute on all the ideas your team has come up with, focus in on the one that you can do well and thoroughly, and wait for the right opportunity to execute on one or some of the others. Note all your design ideas in your project documentation, outlining their connection to your research. If possible, share them with other teams who might be able to design for them. But avoid taking on the development of more than one design idea at a time. Your project has a greater potential for success if you allow the team to focus on developing designs for a single idea.

Once the initial design phase is complete, the team can always go back to the additional ideas. If the research was done thoroughly and with excellent documentation, those ideas will almost certainly still be pertinent. You might even be able to update them, given the work you have done in your first design phase. And in the meantime, circumstances might have developed that create opportunities for design ideas that might have previously not been feasible to now be more realistic. In this way, for the good of your design phase, focus on the design ideas you can most reasonably execute immediately, never leaving behind your other ideas, but putting them on the back burner until you either have time, resources, or a better opportunity to address them.

Case In Point

Veteran Suicide Prevention

In 2017, the Veterans Experience Office undertook a focused project in rural, upstate New York to try to understand and address the issue of suicide among rural veterans. A team of four VEO people and a Lab team member worked for months to connect with private and VA healthcare providers and Veteran Service Organizations in addition to local, county, and state organizations in order to understand the nature of veteran suicide in the area and what was being done to prevent it. In August of 2017, the team presented its findings to both the VA's Office of Suicide Prevention as well as to leaders in the Veterans Integrated Service Network (VISN) 2, which covers New York and New Jersey.

The team provided multiple design ideas that could be pursued to forward the work already being done in VISN 2 and to scale the best practices from the area to other rural areas experiencing similar veteran suicide crises. The solutions were divided into two groups, Immediately Actionables and Need More Research, to give VEO leadership an idea of how the team might proceed immediately and in the medium term. Disappointingly, the team did not get the go-ahead to pursue their Immediately Actionables, and the design phase seemed to whither. In the face of the VEO reorganization, the team was broken up into different areas of specialty, and the discovery research seemed destined to gather dust.

The research, however, was rigorous and sound. A calendar year later, the Centers for Disease Control (CDC) approached The Lab with an audacious idea: apply Human-Centered Design to the problem of suicide among veterans who do not access Veterans Health Administration (VHA) healthcare. Suddenly, the research from that New York State project had new life. It became part of the literature review for the CDC's project. The Immediately Actionables shed light on the needs of healthcare providers in rural areas specifically, while the Needs More Research ideas fed into the direction of the CDC Discovery Phase.

Although not a perfect one-to-one use of the New York State project's findings, the CDC project built upon the previous work in a meaningful way. Currently, the CDC project is itself entering the design phase, and, with one design solution already funded, the team has hopes for the funding of others. So, although a Design Phase opportunity for the New York State research did not present itself, because it was rigorously done and well articulated, it was immediately useful when opportunities for its use arose in another forum.

9. Designs Have a Life Cycle

Creating new work and sharing it with the world is exciting (and frightening); that is doubtless. Through the long, hard Discovery Phase, through all the meetings where the team had to “sell” their vision, through all the emails flying back and forth between the Design and Implementation teams, a lot of work goes into realizing a new product, service, or system. There is a pride, a irrecoverable cost, and an emotional association inherent to a designed thing, but that doesn’t mean the thing has to continue to be owned or exercised by the original team or department that created it.

Products, services, and systems have life cycles, both natural and imposed, usually relative to the amount of time that it takes to build a thing. This idea might feel odd or painful. After all, why go through all the work getting your work into the world if you’re already thinking of how it might exit it? We are not taught how to do this; as organizations, we largely do not talk about letting go or taking apart. Instead, when designed products, systems, or services become dysfunctional, we often blame the people who administer them, or we argue that the dysfunction is simply how things are. However, these are not usually accurate reasons; they are ways to avoid the potential pain of change. Humans fight change; it feels dangerous. Not changing, however, holds us back. For this reason, rather than fight natural life cycles, organizations should strive to acknowledge them and move with them.

Case In Point

Consumer Financial Protection Agency: Policy Sunsets

As a new agency, the Consumer Financial Protection Agency (CFPB, established 2011) took on the massive task of regulating various types of financial entities in the United States. As they scaled quickly, the leadership of CFPB's Human Capital (Human Resources) office understood that, in the rush of bringing on personnel to address such a broad mission, human capital policies ran the risk of being put into place but never implemented. This might not be because the policies themselves were not good ideas, but, instead, because their intended purpose could have been either subsumed by another, adjacent policy, because the policy did not, in fact, mesh with related policies, or because supportive policies were not pursued.

For this reason, the Human Capital leadership instituted a "sunset" rule: any policy that had not been implemented within two years of its articulation would be sunset, or dropped, from the agency's policy books. The assumption was that any policy that had not gained traction in that time was clearly pretty unnecessary to some people. In this way, CFPB's Human Capital office understood that not all their policy design ideas would necessarily take root, and, in response, built in an automatic means by which to set those policies aside.

This is clear thinking, although it might seem a bit sad. However, if a solution does not take root, becomes outdated, or is superseded by another solution, that doesn't mean that the effort going into creating that solution was necessarily wasted. Rather, it means that something has been learned about why things change, about what might cause an idea to not take root, about how and when ideas become outdated, as well as about the natural progression and nature of change, and when and how to allow one idea to supersede another. Instead of keeping design solutions around indefinitely, a better practice is to build in an automatic cycle of re-evaluation for them, so they can be updated if they can and need to be, or they can be sunset, with the reasons why they no longer function becoming part of the knowledge base for new designs.