Systems
Economists divide economies into the two previous categories of activity: manufacturing products, and executing services. This parsing is not quite precise enough for the challenges of design, however. In the design process, we have a third possible category of designed thing: systems.
As was said at the introduction to this section, the public sector is primarily a service provider. Those services are upheld, augmented, and accessed through products. But, especially internally, the public sector also launches and maintains systems that, while not exactly services themselves, are also not exactly products. Systems differ from services in that they, too, uphold services, or even launch the products, but they are neither. One example of this is the hiring system through which the public can enter the government workforce. The website USAJobs.gov is a product that creates access to the hiring system. The action of hiring itself is a service, while the process of getting hired is, in fact a system supporting that service. In this way, the hiring managers, people who write position descriptions, review resumes, conduct background checks, et cetera, are parts of the hiring system, which, as a whole is the service to the American public of hiring.
Case Study: Systems in Government
USAJOBS Mission Critical Hiring Paths Diagram
Teams rebuilding the outdated USAJobs site studied the interactions of USAJobs.gov product and the system of hiring closely. Instead of simply overhauling the site from technical, administrative, public-, or organizational- facing perspectives, the design team brought all these groups to the table during the design process. Each group has a unique value and requirements set for the functioning of the site, and, in organizing that functionality, those values and needs must be balanced. For example, if the designers prioritize technology needs, they might ignore the needs of the people who process the information coming in. If they prioritize administrators' needs, they might not reflect the needs of the public. Even though each of these groups is working towards the same goal, the successful functioning of the USAJobs site, the definition of success differs slightly across each group.
For this reason, throughout their project's development, the designers mapped how the system of hiring worked, where it bogged down, and how it might be reconstructed. They recognized that the hiring system drives every aspect of the sites' functionality, no matter which group a participant or stakeholder might come from. In this way, the effort to improve the USAJobs site became an effort to improve hiring itself, thusly demonstrating the utility of finding and working from the root cause of an issue, instead of solving for discreet, surface issues.
This diagram shows the hiring path of various mission critical positions in the federal government.
A simple glance can show a reader that the system of hiring is complex and involves multiple groups and stakeholders. In building this diagram, the USA Jobs team created an illustration of the hiring path components: people, stages, and touchpoints. Through this diagram, the team was able to not come up with a single solution for hiring, but instead to explore the system, for that exploration to result in understanding it, to clarify nuances in the system to viewers, and to communicate ideas for the systems' many possible throughlines and values in a concise and yet thorough manner. This understanding then informed the development of the USAJobs site product in terms of the various stakeholders' positions and needs in the system.
Diagrams like this one are a common application of drawing and visual communication in organizations. They can be used to give form to systems, and that can be useful. Because systems typically don't have physical, tangible forms, such as this Hiring Paths process or the organizational chart of an office, they can be hard to understand holistically, which in turn limits designers' ability to intervene at the most effective places. In addition to allowing teams to understand the system in order to intervene in it, diagrams, like references, also help teams get feedback on proposed changes to the system in a concise yet multi-layered way. Diagrams can show loops, forks, simultaneous actions, divergences, convergences, and dependencies so that stakeholders can understand their position in the system, and design teams can identify how and where to best intervene with new or improved products and / or supporting systems.