How the U.S. Customs and Border Protection Uses the U.S. Web Design Standards

Apr 12, 2017

As mentioned in our recent Q&A with the team at NASA, the U.S. Web Design Standards team is sitting down with various agencies that are using the Standards. In this second post in our series, we met with the team at the U.S. Customs and Border Protection and learned how they used the Standards to train, develop, and design their various websites and applications.

Screencap of the U.S. Customs and Border Protection website.

Standards team: Why did you decide to use the U.S. Web Design Standards?

U.S. CBP team: Our organization has a lot of websites and applications that support the public, U.S. Customs and Border Protection (CBP), and other law-enforcement entities within the Department of Homeland Security (DHS). These websites and applications have their own unique user experience and learning curves associated with them because technical teams have either inherited these systems from legacy organizations or built them using differing technical stacks and development techniques. To address this, the Common Framework team was established to align technical teams to the U.S. Web Design Standards and U.S. Digital Services Playbook practices. Common Framework develops reusable code, services, and guidance that aid teams in their redesign efforts towards a “common look and feel” for all CBP digital products. Our offering includes a public- and internal-facing front end framework and the CBP UI/UX Style Guide to put into effect the U.S. Web Design Standards. We find that these resources and developer aids are a breath of fresh air for our colleagues at CBP. The development teams use Common Framework products to help them quickly meet foundational CBP requirements without “reinventing the wheel” — such as branding and accessibility; leaving more time to focus on delivering new functionality that strengthens our mission: protecting our country’s borders and facilitating trade and travel.

We encourage our teams to take the common framework and make it their own too. Our team’s mantra is, “we are only as successful as the contributions we receive.”

Standards team: How did you integrate your work with the Standards across your organization?

U.S. CBP team: A lot of what we do is meeting with folks who may not have the frontend skills or the resources needed to enter into a redesign effort. Our goal is to help teams increase their developer productivity and deliver value to users — from the determining the best way to display data to how to optimize their frontend build processes. This has led to a change in our organization’s culture by granting us the ability to market best practices to our internal groups and have an openly shared set of resources that encourages cross-organizational collaboration. We are also saving taxpayer dollars by creating a knowledge bank, promoting a collaborative culture, and fostering shared concentrated resources between groups. We shouldn’t have to write the same code in three different, unconnected efforts for the same type of functionality.

Standards team: What kind of time and cost savings did you see when using the Standards?

U.S. CBP team: The term we like to use is, “Today’s philosophy is tomorrow’s common sense.” Using the Standards, we have experienced both tangible and intangible savings:

  • A developer can create the frontend to an application in 2 to 3 days instead of 2 to 3 weeks. Extend this estimate to the number of developers on staff and cost savings are exponential.
  • Developers can work on several projects versus just one because standards, development processes, and technical stacks are common across the organization – leading to less resources required to create and maintain digital products.

We’re able to accomplish this by using the Standards now to yield savings in the current infrastructure, as well as in the future.

Standards team: What was your experience adding the Standards to your workflow?

U.S. CBP team: Since the beginning of the Standards, our leadership has supported this project and their commitment to change has ensured that technical teams answer the call, as well. The shift towards a culture that promotes knowledge sharing and collaboration across development silos have yielded an abundance of tangible and intangible benefits. We encourage teams to take the Common Framework products and make it their own, too. Gaining buy-in from CBP technical teams is what makes us work. Collaboration is key. The more commitment and support we receive from executive levels and technical teams, the more value and savings we can deliver in the future.

To assist in CBP redesign efforts, we’ve created a “Step It Up” program that provides a step-by-step path for folks to walk through planning, design, and implementation. Our team has also developed a front end starter kit to help those who are unsure of “what to bite off first” with their new project. This starter kit helps those not familiar with the framework jumpstart their setup and begin modernizing their UI. The kit includes the UI code and tools to support the frontend build process.

Standards team: Is there anything our team could do to help you in your efforts?

U.S. CBP team: Yes! Our team could use more guidance on mobile form factors and applications. It would be useful to have guidance UI/UX standards for mobile-first products that we could look to when developing applications for particular devices – such as Android, iOS, and Windows devices.

We’re looking to learn more from agencies that have used the Standards; if you’re interested in talking to us about your experience or have any feedback, feel free to send us an email. You can also chat with the team in the new public Slack channel for the Standards!

This post was originally published on the 18F blog.