Why Governments Need to Look Beyond Digital Experience Design, and Embrace Interdisciplinary ‘Service Design’

Over the past five years, federal, state and local governments have demonstrated their growing realization that good design can have a tangible impact on citizen engagement and public service delivery. Initiatives like the creation of the NYC Digital Playbook, a digital experience design guide for New Yorkers, and Usability.gov are evidence that governments are taking a leap to meet the bar that’s been set by the Ubers and Turbotaxes of the private sector. Despite the push to refocus web-based government services around a user-centered design process, bureaucratic constraints often create a series of roadblocks involving legislation, budgets, complicated processes, and transitions. Thus, government service design deserves an approach that extends beyond redesigning digital interfaces, and rethinks the many components of service delivery, from underlying processes and government policies, to accompanying digital tools. This holistic, all-encompassing approach is referred to as  ‘service design.’

A blog post on gov.uk called “What we mean by service design,” attempts to unpack the complex challenges faced government designers and explains why thinking digital is simply not enough to deliver a successful service. According to the post, “The work of government service designers is informed – and often driven by – digital but we don’t exclusively work building websites or digital things. Some of the biggest challenges in service design are in the transitions between physical, offline, and digital transactions” (Downe). The most successful designs are ones based in archaeology, wherein designers take inventory of the systems already in place, untangle them, reconfigure them, and stitch them together to form a coherent service (Edgar). In addition, designers must consider each layer of service “front to back,” with user-facing components at the ‘front’, internal processes and supporting policy in the middle, and finally, financial and governance structures of the service at the “back” (Downe). It should be kept in mind that digital tools are only utilities within the overall service, which may also employ delivery channels such as phone, physical material, and face-to-face interaction to enhance accessibility and meet user needs.

In Downe’s description of service design, she makes clear that digital and material (which includes processes, budget, policy, governance, etc) must work in tandem to deliver a comprehensive service, and that if one of those components fails, the entire service can suffer. Her blog post recalled the theme of recent NY Times called “Code Breakers: Why is it so Hard to Make a Website for the Government?”, which traces the creation of GetCalFresh, a service intended to turn California’s long winded food stamp application into a three step digital process. In the article, the designers – a government-contracted team from the civic-minded tech non-profit Code for America – faced the task of translating complicated legislation into an understandable process. The first breakthrough came when one designer identified that, despite the wordiness of legislation and the clunkiness of GetCalFresh’s precursor MyBenefits CalWin, the only information legally required to file for food stamps was the applicant’s name, address, and signature (Lu). The designer’s breakthrough was distilled into a sleek-looking prototype which contained an application for food stamps that users can fill out in mere minutes.

GetCalFresh Hompage

GetCalFresh Hompage


Problem solved, right? Little did the design team know that demonstrating a competent digital prototype was only the beginning.

Challenges arose when the design team decided to abandon the clunky, labyrinth-like MyBenefits CalWin website and build GetCalFresh into a user-friendly standalone website (Lu). Unfortunately, because MyBenefits CalWin lack an API, the Code for America team had no reasonable way of funneling applicant’s information from their standalone GetCalFresh site to the MyBenefits database. To put it simply: because GetCalFresh was built externally from MyBenefit CalWin, when users pressed “submit” on their food stamp applications, the state would neither receive nor process the information. To the design team’s dismay, GetCalFresh’s user-friendly interface was not enough to adequately improve the service. In fact, some of their proposed solutions, such as faxing applications from the GetCalFresh website to MyBenefits CalWin, would create more labor for the state’s clerical employees, who would have to manually enter information into the CalWin database (Lu).

The GetCalFresh design team would eventually solve their database issues, but they would encounter more difficulties along the way involving securing funding to iterate on the product, and hire operational staff needed to streamline back-end processes and government relations. In the words of the article’s author Yiren Lu,”it would be a hollow improvement to give CalFresh a better application site without, say, making sure that reminder letters were sent out before an appointment or that the customer-support lines were adequately staffed” (Lu). GetCalFresh is a perfect example of good interface design and good code alone are not enough to ensure the sustainability of a government service.

There is a lot at stake when public services are delivered poorly. For example, low-income residents do not receive food stamps, and filing for unemployment is unnecessarily difficult. Unless each component of the service is immediately understandable, members of the public face challenges receiving the resources they need to survive. In many ways, GetCalFresh is evidence that embracing Louise Downe’s approach to service design is more necessary than ever when designing for government. Integrating design disciplines, or considering design from a procedural, material, policy-based and digital perspectives, is the only way to create sustainable services that citizens can effectively use and understand.

Downe, Louise. “What We Mean by Service Design.” Web log post. Gov.uk. N.p., 18 Apr. 2016. Web. 11 Nov. 2016. <https://gds.blog.gov.uk/2016/04/18/what-we-mean-by-service-design/>.

Downe, Louise. “Common Challenges with Government Services.” Web log post. Gov.uk. N.p., 22 Apr. 2016. Web. 11 Nov. 2016. <https://designnotes.blog.gov.uk/2016/04/22/common-problems-with-government-services/>.

Edgar, Matt. “90% Archaeology: My Notes and Reflections on Service Design in Government 2015.” Weblog post. Matt Edgar Writes Here. N.p., 29 Mar. 2015. Web. <https://blog.mattedgar.com/2015/03/29/90-archaeology-my-notes-and-reflections-on-service-design-in-government-2015/>.

Lu, Yiren. “Code Cracking: Why Is It So Hard to Build a Website for Government?” NY Times. N.p., 10 Nov. 2016. Web. 11 Nov. 2016.

Design Critique: MTA Bus Time (iPhone App)



Early last week, urban planning think tank TransitCenter tweeted a data visualization that presented a befuddling statistic: despite NYC’s growing population and record subway ridership, MTA public bus ridership has plummeted nearly 16% since 2002. TransitCenter’s research indicates that this remarkable decrease in ridership is a symptom of the “declining quality of bus service,” and the MTA Bus Time app is just one component of call to action spearheaded by public officials to rethink and turn NYC’s failing bus system around (TransitCenter).  

Available for iPhone and Android, MTA Bus Time uses GPS hardware to track and communicate the real-time locations of city busses so bus riders can meet the bus by viewing its location on a map, instead of wait for it. Bus Time was created to make taking the public bus more convenient, efficient and reliable for both faithful and prospective riders, and provide a seamless mechanism for finding “…information about when the next bus will arrive at your stop, even if you are still at home, the office, shopping, or dining” (MTA Bus Time Description).

Design Issues

Issue I. Selection screen does not clearly signify the direction of each bus route


After choosing a bus line to track in real-time, users are moved to a screen that says “Choose a direction and stop:,” which provides the names of the neighborhoods and streets where the bus route terminates. In my example above, the directions to choose from are “Greenpoint Meeker Av” and “Lefferts Gardens Prospect Park,” each of which is paired with a “+” signifier to indicate that the option can be selected and expanded.

Seasoned bus riders who frequent NY transit systems know that a choice such as “Greenpoint Meeker Av” means that the bus route is headed toward Greenpoint. For many New Yorkers, this can be inferred because it’s a familiar model used by the subway system – a train that says “Bay Ridge” is headed to Bay Ridge, Brooklyn. That said, new or infrequent transit riders may read the options and think that the bus line begins at “Greenpoint Meeker Ave.” Furthermore, one would need to understand the geographical landscape of Brooklyn to know that Greenpoint is north of Lefferts Gardens. Without this declarative knowledge, it would be easy to make a knowledge-based mistake or a description similarity slip and select the incorrect route direction, thinking the bus bus is headed in the opposite direction or maybe even to an entirely different part of Brooklyn.

On this screen there is also a signifier called “Map,” which allows users to visualize the bus route and creates an expectation that this will help choose the correct bus route direction. When “Map” is selected, however, the map only shows a real-time visualization of where the busses are located along a highlighted route, where neither the stops nor destinations are labeled. The map, while simple and by all means understandable, still does not help users understand which bus route direction to choose on a previous screen.


One solution to a knowledge-based situation is to provide users a solid understanding of the direction in which the bus route is headed. In this case, that understanding can be achieved by affording users a way understand their destination when they select either “Greenpoint Meeker Av” or “Lefferts Gardens Prospect Park.” Perhaps instead of a button in the right hand corner that simply says “Map,” a map automatically appears beneath both selections. Then, an signifier can be added next to each route direction to “Show Bus Route,” which highlights the route, its direction, and its destination. This helps users visualize which direction they are headed, and where they will end up geographically.


Issue II. List of bus stops lacks visual context signifiers to communicate that it’s a real-time bus route


The bus stops displayed in the image above appear as list, but at first glance its unclear that the stops are in order by location along the bus route. In order to understand that the list is symbolic of a route, one would need to navigate to the “map” feature in the upper righthand corner, which displays busses traveling along an unlabeled path. There are no signifiers to connect the bus stops to their location on the map until the user descends one level deeper onto the individual bus stop screens. Despite bus stop list screen’s cleanliness and simplicity, the design lacks signifiers that call upon cultural conventions to convey that the we are looking at bus stops, listed in order, on the B48 headed toward Greenpoint.

For example, on the subway, stops are usually placed along a line to indicate a “path” with dots or symbols along the way to represent each stop. The stop names are given context by the convention that routes and trajectory are displayed as lines, and breaks in that line symbolize stops. Below, an example from an MTA train car maps to the real-life model of the subway: the train follows designated path and makes multiple stops along the way. MTA Bus Time’s presentation of bus stop names as a simple list is meaningless without more contextual signifiers.


Add simple visual cues to the interface, such as a line with dots along it, to align with the cultural conventions established by the successes of public transit system around the world. Instead of displaying a sparse list of bus stop names, a presentation with these added visual cues conveys that the list is in fact representative of a bus line. The example below creates a familiar experience that clearly indicates the purpose and meaning of the words on the screen. An added signifier shows a bus icon “at stop”, pulling real-time transit information into the list to make it come alive and map to the conceptual expectation that busses are running along the route. This feature also eliminates the need to switch between screens to see where the bus is currently traveling along the route. Interestingly, the display below is the desktop view of MTA Bustime, which has a radically different design than the Bustime iphone app.


Issue III. Signifiers don’t always indicate the actions they suggest.

In the “Nearby” feature, there is an option to “See more” below the list of busses that service each bus stop. The signifier implies that there may be more busses that run along the route, and that by clicking “See more,” one can learn about additional options. Instead, the feature directs users to a screen with arrival information for each of the busses listed. This is just one instance of signifier failing to map to user expectations, and confusing the user by affording a result that was unexpected.


The suggestion for this issue is simple – instead of “see more” at the bottom of the bus list, change the placement and text of the signifier to reflect the affordance more accurately. In this case, I suggest “See more” be removed, and a signifier with text that says “Check Bus Times” be placed next to each bus route on the list.




TransitCenter. “As Bus Ridership Plummets, Leading Experts Release Solutions to Fix NYC’s Struggling Buses.” http://transitcenter.org/wp-content/uploads/2016/07/Turnaround-Bus-Campaign-Launch-Press-Release-7_20_16.pdf