But does it have to?

At this year’s Drupal GovCon, we were able to speak about designing for government to project managers, designers, and developers – and we are going to share our most important points. To successfully complete government projects, we advise considering the following four steps:

1) Understand the issues. Why are government projects so difficult?

Testing for government projects is structured.

In government, there is a lot of red tape. Lots of stakeholders. Lots of headaches. There are limits on the number of people you can talk to, given certain assumptions and situations. Government projects can be wildly inflexible with regard to speaking to the right people and accessing the necessary pieces of information. 

Although arguably one of the most difficult parts of government projects, it is critical to understand and learn the structure of your government client as well as you can. Project timelines need to support and account for restrictions. Resources need to be put toward getting the right stakeholders in the room. 

You aren’t designing for the right people. 

Your website,  digital presence, and communication strategy should have clearly defined goals and objectives – otherwise known as your business cases. However, you should not be designing specifically for these business cases, nor for your board of trustees, your agency hierarchy, nor your boss. Doing so leads to competing priorities, lack of navigational focus, and general confusion for your actual audiences. 

Clarity is key. If your website needs a glossary, you may need to think about who you are talking to and how to better communicate with them. When we aren’t designing for your actual audiences, we tend to fill the void with our surroundings. 

Government websites are the result of government environments. 

Without inputs from your current or potential users, websites can be seen internally as a digital version of your agency or organization. 

This leads to department-based navigation, unclear or overly technical content, taxonomy influenced by internal processes and document-filing methodology, and perhaps worst of all, replication of the same red tape you face internally, in your own website. 

Your team may not be working on the same problem. 

Often times, project teams are split between duties — UX, design, dev – both front and back end. Embodying the “we are all designers” philosophy and bringing the full team together throughout a project build will result in a more cohesive delivery, as well as a shared vision. 

So how do we fix these issues? 

2) Get to know your users. Who are they? What do they want? 

The user you should be designing for isn’t your boss or someone within the hierarchy of your organization. Those people exist, sure, but they are the business case owners. What they want is important, but it will not tell you much about what your actual users want. 

The right users are the people who will actually interact with your website. They will decide the success of your digital offering. In order to be successful, you must present information and functionality in a manner in which your end users expect it and can easily comprehend it.

Within government projects, it is often difficult to identify and learn more about these target audiences. If you don’t have the timeline or the access you need, get creative about who you talk to. Look at your organization and find the folks that do interact with your audiences directly. This could be those responsible for your social media channels, people who receive and respond to email traffic, or if your agency has a phone bank, those who answer the phones. 

The closer you can get to your audience, the more reliable information you will receive about their behavior and what they are looking for. The further away, the more assumptions and business case logic you will be integrating into your solution. 

3) Navigate complicated environments. What needs to be on your website? No, really – what NEEDS to be on your website? 

When too many internally driven assumptions and too much business case is integrated into your web presence, you will likely find that it looks and sounds a lot like your agency. An overly complicated and siloed organization structure will translate into a web presence that lacks clear user pathways and is generally difficult to navigate or to find relevant and useful information. 

An unfocused and unprioritized web presence can sometimes lead to everything and all the things being featured at the very top level of the website. This forces your users to learn by trial and error, not unlike the process of trying to navigate a maze. 

When you aren’t accounting for the actual user of the website, the way in which you present information and functionality can end up looking like a different language. The government is notorious for using jargon, insanely long acronyms, and an overly technical vocabulary. This is okay in your daily interactions with your agency because they are expected to know the terminology. However, you shouldn’t expect the users of your web presence to know this.

If resources are limited — or giant workshops aren’t in scope — anyone in the project can run trimmed-down user journey activities with whatever user-facing people you can find. Using these simple prompts can force them to think about the problems and solutions of the website in a more holistic and user-centric way. “I am a….” “I need…” “So I can…”.

Clear and concise concepts about your audiences can lead to a much stronger vision. 

4) Create a shared vision. Does everyone agree? 

Having a vision is very important. Having a shared vision across your implementation team is just as important. Every member of your team is designing something, whether it is in photoshop, in browser, in code, or in omnigraffle. Each member of a project team is creatively responsible for a portion of your project. If your team is not designing together, the results can be chaotic.

Simply put, a shared vision makes a better project. Projects with a sole creator and owner of vision can result in poor quality outputs. Projects where the vision is not well understood or subscribed to will not support that vision across the many facets and aspects of the solution. Shared vision ensures that the output is cohesive and a product of clear direction as well as one your team will be excited about. 

So how do we achieve shared vision? 

Recognizing that creative input on projects is not solely  limited to the designer. Set time aside throughout the course of your project to work together on everything from discovery to implementation. Ensure that the entire team understands and has experienced the problem you are trying to solve. Empower and position team members to own their work. Listen and acknowledge. 

Any of these recommendations can be incorporated into your project, at any stage. Feel like you are already off the rails? Do a retrospective, and talk to your team about the work you’ve done thus far. Talk about what it is you are trying to accomplish. Empower everyone to share their thoughts about how the project can be better and how you can work together more effectively.