Category: Business Operations

Collaboration: Are we actually achieving it?

Common definitions for Collaboration are:  To work with others to complete a task and to achieve shared goals; to cooperate with others with which one is not immediately connected (taken from Wikipedia).

These definitions are pretty basic.  Experience, however, has taught me that collaboration is a complex concept within most organizations.  read more

A Transformation Midterm Report

Organizations are implementing many complex changes concurrently and within short time frames. Senior leaders continually add new priorities to their organizational workloads, ensuring a perpetual state of transition. We continue to expect staff to deliver quality services and products to internal and external clients. It’s official, we have entered a state of being over-committed.

read more

Priority Agenda Items for Senior Leadership Committees

Through working within the public sector transformation over the past four years, I have witnessed the state of perpetual transition playing out across government departments and agencies with startling consistency. It’s no surprise that within the current climate, staff is struggling with the concept of a clear vision of the future.  When everything is in transition, and there appears to be no end in sight – this is a very common challenge.  read more

Five 2014 Public Sector Predictions: Looking Back to Look Forward

As health-based resolutions ramp up across Canada to counter last month’s holiday socializing, the Canadian government jumps into 2014 with a slate of promising initiatives designed to trim the fat, so to speak, from the public purse. A review of how some of those initiatives initially fared in 2013 says a lot about what could or could not work in the government’s favour in the coming year. read more

Best Practices: Rationale or Rhetoric?

As consultants we get asked to develop a content strategy, governance model or performance management framework based on “best practices”. In response we cite research studies, analytics and trends or methodologies in user experience design or web strategy that have become commonplace in the field and have yielded results for our clients.

read more

Content Strategies to Prevent Future Government ROT

The push to remove Redundant, Outdated and Trivial (ROT) content on government websites has allowed departments and agencies to reconsider what content is needed by different audiences, and how those audiences want that content delivered. We’ve observed productive discussions across the National Capital Region over the past year on the purpose of the web channel and how it can both help users do the tasks they come to website to do and departments promote their new initiatives and programs.

ROT exercises however are often framed as a project and not a way of doing business. This creates the risk of falling back into an old pattern, which is publishing content that is of little value to users and/or doesn’t successfully increase awareness or engagement with government priorities. We’ve seen one department undergo a comprehensive content “pruning” two years ago, only to have their content holdings balloon by 246%, a mere 24 months later.

A major contributor to the persistence of ROT is the lack of anything that helps us determine what should and shouldn’t be published. This is a content strategy. Content strategies define:

  • What goes on the web and why
  • Which content aligns with which tasks
  • How web content should be presented and structured
  • How to balance user needs with organizational priorities
  • Who makes decisions on the web
  • How content will be optimized for findability and promotion
  • How web performance is measured

An effective content strategy requires involvement by a multi-disciplinary team comprised of communications and information management specialists, senior and program management and IT. In a Government of Canada context, the strategy should align with these success-centric drivers:

  • Program Alignment Architectures (PAA)
  • Strategic business plans
  • Enterprise business architectures
  • Content standards
  • User research (identifying tasks and demographic data)
  • Communications plans for web campaigns

This admittedly is not a small effort, but it is one that can be incrementally developed as time and resources allow. A work plan that incorporates one or two elements can be managed on a quarterly basis. Using this phased approach, the elements that support smart decision making for the online presence can build over time and improve outcomes that are valued by the organization.

April 2013: Why does this matter now?

We know the Government of Canada is consolidating into a single government website but we don’t know much more than that at this time. This leaves departments wondering if they should do anything at all. A content strategy approach is one of the best things you can do to prepare yourself for the future in the absence of knowing exactly how things will play out. On the one hand, if there are delays to the consolidation exercise, you have put some foundational pieces in place to improve the user experience for your audiences. On the other hand, if things move quickly, you have a precise understanding of what you and yours users need out of the web.

Denise Eisner is a Senior Consultant in the Government Service Excellence practice.

Web Renewal: It’s not all about Users

You read that correctly: developing an effective web presence means it’s not all about users. My colleagues and clients who have heard my relentless ode to user-centric design might be spilling their lattes about now. Lest anyone think I’ve lost my senses, let me add a bit of context.

The discipline of user-centred design takes into account many aspects, including detailed knowledge of user tasks, user behaviours (accessing a site at particular times), conventions in interface design (having a search box available on every page), and a laundry list of known ways that humans interact with a product (we are attracted to images of the human face). Our approach to design thus attempts to grab all this knowledge up front, analyze it and then come up with a design approach that is defensible based on the inputs.

Yet this research-driven approach can overlook an important driver, and one that flies in the face of user-centricity. If we also care about success-driven design, then how do we define success? We could define it by users who complete tasks. We could define it by the clarity of our navigation labels. That is common practitioner thinking and I’m guilty of it as well.

The person who cares most about success is the head of the organization, i.e. CEO, Deputy Minister, or Senior Department Official. They deeply care about success and make sure their managers care about it too. Government departments’ Program Activity Architectures (PAAs) and Business Plans codify the measures of success for their organizations. So why don’t we consider these measures of success?

The answer is fairly simple: senior management has yet to frame success in terms that meaningfully translate to the web. By the time the PAA comes out, perhaps with an associated performance measurement framework, success is defined as page views. These might have been interesting metrics ten years ago, but organizations with mature web performance strategies have abandoned that as a viable measure of success. Visiting a web page no longer cuts it (the user might have come, saw, and left in 5 seconds). So as Web practitioners and strategists, we have to start demonstrating how success should be measured against departmental priorities and communicating that up the chain, for example, as the percentage of users who do or do not:

  • Repeatedly visit a site and/or consume a minimum amount of content or a specific set of pages related to a departmental priority;
  • Are willing to share our priority site content with their personal networks;
  • Begin an RSS subscription to get content updates about a new initiative;
  • Participate in online consultations.

So how do we communicate up? The successful Web teams I’ve seen in government have created open lines of communication all the way to the DG of Communications, and that person, who cares about success, becomes the lead evangelist at the senior management table. Among his or her peers, their understanding of how the web can move the organization forward on its objectives carries weight. So we inform, we educate and we demonstrate to the DG through a series of small successes how the right kind of measurement can demonstrate bigger success for the department. We showcase, we pilot and we test, test, and test our designs to give evidence of improvement. We build research plans and performance frameworks and we share our progress with the DG on a regular basis.

And we never give up.

Denise Eisner is a Senior Consultant in the Government Service Excellence practice.

Web Accessibility from PDFs and Apps to Project Planning: A conversation with Derek Featherstone

On November 20, Systemscope co-hosted a talk with Simply Accessible’s Derek Featherstone about accessibility and usability in light of the fast-approaching July 2013 TBS Web Standards on accessibility and usability compliance deadlines.  Shortly after the talk, I met with Derek to go over some pressing topics our attendees had that we didn’t have time cover at the event:

  1. PDFs and Accessibility
  2. Meeting GC Web Standards Deadlines
  3. The Best of All Possible Worlds
  4. Testing for Accessibility

1. PDFs and Accessibility

What’s your take on making PDFs accessible?

PDFs are often published in that format because it is convenient for the publisher more so than the person getting the information.  The first question to ask is whether the content should be published in a PDF format or not?

If the decision to publish in a PDF format has been made already and it’s a standard operating procedure, what can be done to make the PDF accessible?

For a report, a strategy for dealing with publishing to PDF is to publish the report from pieces that are initially accessible, instead of trying to convert a PDF to its HTML equivalent. An accessible PDF can be just as accessible as HTML.

Some things to consider for building accessible PDFs:

  • Build the report using an accessible Word template
  • Make sure the reading order is right and that all the image assets have alternative text
  • When creating big reports that are built in Word and merged with Excel tables, make sure there’s an accessible baseline or template that exists.

Is it possible to retrofit PDFs and make them accessible after they’ve been produced?

You can take the PDF that’s produced and fix it, which can be very time consuming if you’re not a PDF accessibility expert.

To retrofit PDF format documents you can go back to the source document and once you make the source document accessible, you can regenerate the PDF as an accessible PDF. This can be efficient because it then becomes reusable. You can also employ a service from PDF accessibility experts to fix up your PDFs.

Overall, spending money to retrofit PDFs after they have been published is one-time money spending.  Creating PDFs from accessible templates that have been built before publishing to PDF gives you a multi-use accessible production baseline.  The money invested upfront to create those templates can be more effectively spent than spending time and money retrofitting PDF documents. Of course, this really does vary depending on how complex your PDFs are. In some cases it might be just as cost effective to have them converted to accessible PDFs by a 3rd party.


2. Meeting GC Web Standards Deadlines

With the compliance deadlines looming, are there any other pragmatic takeaways you can offer Government of Canada web professionals who are now racing against the clock to meet the standards?

Any takeaway depends on the types of work you’re dealing with.

For document-centric accessibility work:

  • Start by checking the overall structure and making sure there is a page structure that exists. Whether it’s in PDF or HTML format, there should be properly tagged headings, lists, paragraphs and alternative text for images.
  • If your documents are not interactive, i.e. forms, and your accessibility compliance tasks centre around content, check image assets that are included to make they are located in the right place on the page.   For example, check that an image at the top of the page is not related to a paragraph at the bottom of the document.

For web applications-centric accessibility work:

  • Deal with your most important assets first by asking if this is a mission-critical application that has to be made accessible.  For example, at the Canada Revenue Agency, a payroll calculator is an employment-related application that everybody needs and that is central to the CRA’s service offerings.
  • If your application is a map, try to understand who is using the map and for what purpose.  Too often, web accessibility is reduced to blind people who need to ‘hear’ the application to use it.  If, however, the mapping tool is one that requires the user to draw a map to then calculate the area, accessibility moves beyond blind people using the application to people who might need a keyboard accessible way to ‘draw’ the map.  Other people might be using voice recognition software to use the application.  The understanding around web accessibility has to move beyond blind people to understanding different interfaces for different users.

In many cases, when attempting to retrofit applications, it becomes obvious that the wrong tool was purchased to accomplish the task. That’s when usability testing and understanding user needs and tasks is critical to accessibility.


3. The Best of All Possible Worlds

What would be an ideal Government of Canada scenario in terms of web accessibility for you?

When we work on large-scale accessibility projects, we try to cover off five pillars:

  1. Planning
  2. Procurement
  3. Professional development
  4. Process
  5. Policies

These pillars are not sequential, but they have to exist.  From a process sense, you need to make sure your entire software development lifecycle takes into account the needs of people with disabilities from design to testing to roll-out.

From a procurement standpoint, we would ideally have the proper tools that are accessible in the first place.  For service procurement, requirements have to have accessibility built into the final deliverable.  Sometimes, vendors will say that a tool or piece of software is accessible, only for clients to find out that it hasn’t been tested appropriately or evaluated properly for all dimensions of accessibility. Other times, vendors will understand document-centric accessibility but not web application accessibility.

We often get called in to evaluate third party work to assess whether the tools or applications that have been delivered meet people’s accessibility needs and standards.  We work as an advocate for the client since they might not know or have the time to understand all the dimensions of web accessibility.


4. Testing for Accessibility

Is it possible to do accessibility tests in-house rather than post-purchase or pre-launch?

A good place to start is with the WCAG checklist and being to understand how to interpret it.  The expertise to interpret the checklist takes years to develop, but there are W3C resources on WCAG out there with techniques on how to test accessibility and usability and why it’s important.  Often for clients though, it’s easier to get somebody else to come in and assess the work for you.

How is that important to an enterprise-level project?

If you’re not making professional development and continuous improvement part of an overall program to achieve accessibility and treating it as a one-time project, the work won’t be sustainable.  Training on accessibility, whether from a technical, compliance or user experience dimension gives you a base that goes beyond a one-time project.

When we give training sessions to various clients, whether they are designers, quality assurance staff or testers, we offer an initial assessment of their project and how to fix it.  More importantly, we help them fix it and teach them how to avoid the issue in the future.  Knowing how to avoid issues and fix problems takes accessibility out of project mode into a built-in process that’s part of a bigger program.

Embarking on a redesign takes years to accomplish instead of fixing other more basic problems on a day-to-day basis.  Compliance to these new standards should be a starting point, not an end point.  Executing these compliance standards is the beginning, not the end.  Accessibility and usability should be part of a continuous, iterative process, not a one-time annual project.

With that, our conversation came to a close.  In sum, with a fast approaching compliance deadline, well-planned, prioritized efforts to meet accessibility will enhance usability while also realizing operational efficiency and improving overall user experience.


If you are interested in attending future Systemscope Lounge talks about the Government of Canada web presence, please contact Denise Eisner ( to be included on the mailing list. We appreciate all inquiries, but preference is given to Government of Canada professionals.