Digital Governance Policy
The development of the Harvard University Graduate School of Design website (staging.gsd.harvard.edu) and other public official GSD digital properties represents a significant investment, and plays a key role in strengthening the School’s public online image. It is, therefore, of vital importance that our community maintains gsd.harvard.edu, its subsites, and other public digital properties according to best practices, institutional policies, and at the highest quality possible. With that goal in mind, this document details the online management and governance of the GSD’s public digital environment.
Digital governance pertains to people, policies, procedures, standards, and guidelines that govern the creation and maintenance of our official website and other public digital properties. These include all pages managed in the Content Management System (CMS) and subsites created and managed within gsd.harvard.edu, externally focused applications and services, social media sites, mass emails and e-newsletters, as well as other tools supporting public e-communications, and all media hosted on external sites. This policy does not pertain to websites, digital tools, or educational technologies that are not intended to be shared publicly, including those for internal administrative use or for use within courses, studios, and other non-public learning groups.
- Governance Structure
- Governance Policies
- Policies and Procedures for GSD Websites
- Social Media
- Emergency Action
The primary objective of this document is to provide collaborative centralized governance for the ongoing development, deployment, delivery, and maintenance of the GSD’s public online presence and to represent the GSD brand consistently across public digital channels through standard processes, roles, responsibilities, and practices.
This objective will be pursued with the school’s underlying strategic priority in mind: to facilitate a user experience that will develop a lasting digital relationship with all visitors—particularly current and prospective students, faculty, and staff—providing them with the information they need quickly, easily, and enjoyably.
2. Governance Structure
The Digital Governance Committee is composed of the assistant dean and director for communications (co-chair), the assistant dean for information services (co-chair), the assistant dean for information technology (co-chair), key members of the GSD’s core web team, and other GSD community members who may be invited from time to time.
It is the responsibility of the Digital Governance Committee to set the direction and policies for the GSD’s public online presence, including the school’s official website and the web operating environment based on best practices. In order that directions and policies are set with a full understanding of the issues and impact of any given decision, decisions appropriate to the jurisdiction of the Digital Governance Committee will be reached by consensus. If the group cannot reach consensus, options will be presented to the GSD’s Executive Committee with a recommendation for resolution.
Responsibilities of Digital Governance Committee include:
- Establish appropriate policies, processes, and procedures to govern digital strategy and standards for public GSD-branded communications
- Evaluate effectiveness of policies and standards
- Ensure compliance with all legal and regulatory standards, including accessibility, security, privacy, etc.
- Authorize global changes to taxonomy, structure, branding, look and feel, navigation, styling, etc., as
- Recommend new templates or changes to existing templates
- Ensure quality, consistency, and content integrity across digital platforms
- Facilitate and resolve non-compliance issues
The Digital Governance Committee will meet at least once per semester to review requests from academic and administrative stakeholders for major changes to the GSD website, other digital properties, and/or relevant policies and procedures. They will update the Dean and Executive Committee on project plans and disseminate information to their staff and department members, as needed.
Throughout the year, community members are invited to send ideas, requests, problems, and concerns to the Digital Governance Committee via email: GSD Web Staff. Ideas, requests, problems, and concerns will be logged into a ticketing system and reviewed with the committee on a semester basis.
3. Governance Policies
The GSD’s main website, subsites, e-communications, and social media sites provide public platforms for showcasing the school’s best qualities and projecting a positive image of the School to the world. They are strategic assets that carry enormous influence and provide global access to multiple aspects of the School. With a distributed content team managing these sites, guidelines that encourage clarity, accuracy, and consistency are essential to protecting the GSD’s online image. This document aims to cover most areas of digital governance, but if you have questions that are not answered upon reviewing this document, please contact the Office of Communications.
The website gsd.harvard.edu is the sole property of the GSD. While designated staff will have access to edit certain portions of the site, create new content, and remove old content, the site and all its subdomains remain the property of the School.
4. Policies and Procedures for GSD Websites
A ‘GSD Website’ is any website, including gsd.harvard.edu and all subsites (as defined below), that purports to represent the views and activities of the GSD community, that is owned or managed by any GSD staff or official student-organization, or that uses any GSD branding. Any such website must be approved by the Digital Governance Committee, and is subject to all of the requirements in this document. Please see section 3.2 on GSD Subsites (below) for information about how to request approval of a new GSD-branded website.
Content Management System
All content currently is held and propagated to gsd.harvard.edu using the WordPress Content Management System (CMS). No other software product may be used within GSD’s approved CMS and its build architecture. Additional sites, upon approval, may be linked to gsd.harvard.edu when appropriate. Content editors located in offices and departments across the School are expected to ensure all links are live, tested, and appropriately implemented on the pages they are responsible for updating.
Staff who have received training in the GSD’s custom implementation of WordPress and its governing policies and procedures will be given access to the CMS. The Office of Communications will provide initial training, after which content editors may utilize various support documents available in the resource section of the GSD’s website. Access will not ordinarily be granted to students, faculty, or temporary workers.
Roles and Permissions
Permissions in WordPress are determined by roles, which are generally the same for all editors assigned to that group (e.g., all users in the “GSD Contributor” group have the same editing privileges). Department administrators should contact the GSD Web Staff to request editing privileges on behalf of employees.
It is recommended that department administrators maintain a list of current content editors. Department administrators should contact GSD Web Staff when editors should no longer have permission to edit the site (e.g., when an employee changes jobs or leaves the GSD) or when new staff should be eligible and should be trained.
Contributors have the ability to edit existing site content and work with the Office of Communications to create new web pages. In addition to “Pages,”
- Contributors with Human Resources and Faculty Planning functions may have the ability to edit
- Contributors with Academic Administration functions may have the ability to edit “Courses”
- Contributors with Communications functions may have the ability to edit “News,” “Events,”
“Exhibitions,” and “Publications”
In addition to the Contributor roles defined within our CMS,
- The Office of Communications is responsible for generating and maintaining content for the
homepage and top-level landing pages, and provides content writing, editing, organization, and design guidance to departments school-wide.
- Academic Chairs and Department Directors are accountable for:
- Recommendations regarding content direction for their webpages that aligns with the
school’s strategic web goals and the established site structure
- Ensuring that department site content is accurate, up-to-date, follows best practices for web
content and usability, and meets the school’s quality standards
- Coordinating with their department administrators to ensure that an editor is assigned and
trained to maintain their department pages. It is generally advisable to assign one or two individuals at most who will regularly work in the CMS and gain both the experience and knowledge to become experts in the use of the system.
- Recommendations regarding content direction for their webpages that aligns with the
Maintaining the quality and accuracy of the GSD website is a shared responsibility that needs to reflect the brand, mission, and values of the institution. Typos, poor grammar, outdated information, etc. detract from effective communication of what makes the GSD an outstanding place to study, live, and work.
The school’s Office of Communications has access to all areas of the GSD’s main website and social media channels. To ensure quality control, the Office of Communications may edit or alter content as needed or as possible for clarity, consistency, and style to ensure quality control and to conform with school naming conventions and branding. The GSD reserves the right to revise or delete content housed either on school resources or external resources that does not meet acceptable use guidelines or the standards outlined in this policy.
Department administrators are responsible for ensuring the quality and accuracy of all content changes made on their department pages. If error(s) appear on a page, the Office of Communications will correct the error(s) and contact the Contributor responsible to advise on GSD style and best practices. If quality control issues recur, the Office of Communications will relay the concern to the department administrator and may suspend editing privileges until it is resolved.
An annual content audit will be conducted on all department web pages. It is expected that academic and administrative department heads will consult with communications staff in reviewing their site audit and will take an active role in addressing issues regarding content on any given department or program site.
Change Management and Classification of Changes
Changes to the GSD website may arise reactively in response to problems, or proactively from seeking improved efficiency or effectiveness, as well as to enable or reflect institutional goals and priorities. Change Management ensures that standardized methods, processes, and procedures are used to facilitate efficient and prompt handling of all changes and maintain the proper balance between the need for change and the potential detrimental impact of changes. Changes are classified as follows:
- Fixes: A fix can be an urgent, unplanned change (aka a “hot fix”) or a planned change that goes through the standard release and deployment process.
- An “Emergency” is defined as a change required to immediately restore service or to avoid an outage where no other workaround is available.
- An “Error” or “Bug” is defined as a deviation from expected behavior that does not require emergency change handling and where a workaround is available. Examples of “bugs” include incorrect data fed from third party services, inconsistent cross-browser support, errors in site search, etc.
- An “Urgent Bug” is an error that impacts core functionality (e.g., site search), operations (e.g., course directory), or system performance, or that exposes the school to security or legal liability (e.g., Harvard Key authentication errors or failure to meet University guidelines for accessibility). Bugs should be reported via the Error Report Form.
- Enhancements: Enhancements are planned changes that go through a review and approval process.
- A “Small” change is defined as an update to existing content. “Small” changes can be implemented directly in the content management system by an authorized Contributor (defined above under “Roles & Permissions”).
- A “Medium” change is defined as any change that impacts the information architecture, organization, and search engine results of the site. Examples of “medium” changes include modifications to site navigation, the creation of new pages, or the reorganization or renaming of existing pages.
- Medium changes must be implemented in collaboration with GSD web team members with specialized knowledge of best practices in content strategy, web usability, information security and accessibility, and search engine optimization (SEO). Medium changes may require approval of the Digital Governance Committee. Requests should be submitted via the Enhancement Request Form.
- A “Large” change is defined as any change that impacts the data structure, theme, or functionality of the site. Examples of “large” changes include the creation of new sections or content types; modifications to the look and feel or user interface design of the site; adding or removing attributes of a data type; modification to an existing feature; creation of a new form, feature, or interaction; integration with a third party system or service.
- Large changes must be implemented in collaboration with GSD web team members with specialized knowledge of best practices in web design and usability, information security and accessibility, and web development, and have experience with the GSD’s custom implementation of WordPress. Large changes typically require approval of the Digital Governance Committee. Requests should be submitted via the Enhancement Request Form.
Change Management Process
The Change Management Process begins with the identification, recording, and classification of the change, and continues with its review, approval, scheduling, development, testing, and staging for implementation. Changes must be submitted with appropriate lead-time to allow the web team to perform these tasks and to ensure that individuals impacted by the change receive adequate notice.
- Request Change: All “Errors” or “Bugs” (defined above) should be reported via the Error Report Form. Errors reported via this form are automatically logged in a ticketing system and reviewed by the core web team. “Emergency” errors will be addressed immediately. “Urgent” errors will be scoped and prioritized upon receipt. Non-urgent errors will be scoped and prioritized along with other change requests during weekly meetings of the core web team. Requests for Medium or Large “Enhancements” (defined above) should be submitted via the Enhancement Request Form. A member of the GSD web team will respond within two to three business days.
- Define Scope and Impact: Defining the scope of a change includes identifying the platforms impacted; cost of development; maintenance requirements; units or departments affected; business case or rationale for change; alignment with known strategies and stated objectives; potential conflicts; skills or expertise required to implement the change; availability of internal or external resources; and an assessment of institutional and technical risk. This data is used at many decision points within the process. Examples of questions used in assessing the risk or impact of a change:
- Who will the change affect?
Business units or departments
- What will the change affect?
Sites, sections, or pages
Platforms, systems, or services
Data models, feeds, or flows
Internal processes or workflows
Branding/Look and feel
- What is the impact on?
Other scheduled changes
Other business units or departments
Search engine results
Other resources (budgets, staffing, security, etc.)
- What are the institutional objectives that will be used to measure success after the change has been implemented?
- Who will the change affect?
- Approve, Reject, or Modify Change: Change requests will first be reviewed by the core web team. After review and initial scoping/risk assessment, the web team may either approve or reject the request. Every attempt to resolve issues or conflicts will be made prior to rejecting a change, including suggesting modifications to the scope, design, or timing of the original request. If there are questions about the appropriateness or feasibility of a request, it will be referred to the appropriate technical or communications lead for a decision. If a decision cannot be made or the requesting party disagrees with the decision, the request will be reviewed by the Digital Governance Committee, which will make the final decision. Note that any change requiring significant resources (e.g., more than 20 hours of developer time, hiring external resources, coordination with third-party vendors, acquisition and implementation of new software or services) must be approved by the Digital Governance Committee.
- Prioritize/Schedule Change: Every effort will be made to implement changes in a timely manner while recognizing the need to balance required maintenance, upgrades, and fixes with desired enhancements to existing content and functionality. Following approval of a change request, the web team will use their judgment to prioritize the request among other planned changes. If a change involves high risk, it may be scheduled to minimize impact (e.g., during intersession or summer break). Technical or operational interdependencies discovered during the review and scoping process may also affect timing. If the requesting party disagrees with a scheduling decision, it will be reviewed by the Digital Governance Committee, which will make the final decision.
- Implement Change: Implementation of an approved medium or large change may only be performed by the GSD web team, a staff Contributor working in collaboration with the web team, or a designated vendor. Changes will be deployed to a web staging environment for review and approval. Upon approval, the web team will follow the standard release and deployment process. Documentation of changes will be stored in a common location to allow for coordination among team members. Criteria for a successful change include:
- The change was implemented in accordance with the implementation plan
- The change was implemented within the planned implementation timeframe
- The change met anticipated objectives defined in the Change Request
- The change did not cause unplanned impact to business units, departments, or end users
- The change did not result in a system outage
Requesting A URL Redirects
A URL redirect automatically forwards a user from one URL is to a different URL. There are a few reasons why a redirect might be needed:
- The page or file needs a human-friendly URL for sharing.
- A logical alternative URL is needed for GSD section.
Example: the URL https://staging.gsd.harvard.edu/library/ redirects site visitors to the URL https://staging.gsd.harvard.edu/frances-loeb-library/
These requests are evaluated on a case by case basis, and are implemented by the GSD’s Web Team. To request a redirect, please fill in the Redirect Request form and a member of the Web Team will get back to you within 2 business days.
4.2 GSD Subsites
A Subsite is a website hosted under the GSD’s domain name, that bears the school’s name or logo, or that otherwise purports to represent the opinions or work of the GSD, but is not directly part of staging.gsd.harvard.edu. Subsites must be sponsored (“owned” and “maintained”) by a current GSD faculty member or administrator and be related to a GSD-affiliated research center, design lab, program, student group, or initiative. All new GSD subsites must be approved by the Digital Governance Committee (see below). Subsites must meet the following criteria:
- Support the GSD’s mission
- Provide lasting value to the school
- Satisfy an unmet need
- Have approval from the Digital Governance Committee
- Have an ongoing staffing and maintenance plan
- Demonstrate adequate funding to meet start-up and ongoing maintenance costs (if school funding is not available)
- Register relevant ownership and technical details with GSD Web Staff, enabling GSD Web Staff to make changes in hosting plans or content, as required or needed
Requesting a GSD Subsite
To request a new website, sponsors or administrators should fill out a New Site Information Form. A member of the GSD’s web team will respond to your request promptly, as conditions allow.
Student groups should contact the Office of Student Affairs to request approval for a new website. Once the Office of Student Affairs has granted approval, the request will be sent to the Digital Governance Committee for final approval. Student groups must be officially recognized by the GSD to receive approval for a subsite. Please visit the Student Group Directory for a list of active student groups.
An Unauthorized Subsite is a website that purports to represent the opinions or work of the GSD or uses the GSD name or branding elements and has not been approved and does not meet the requirements for a GSD Subsite set forth above. In the event that GSD Web Staff become aware of an unauthorized subsite, GSD web staff will attempt to contact the site creator(s). If the responsible parties can’t be contacted, GSD Web Staff may take all possible measures to assume control of the site or to have it taken down. If the unauthorized site creators are responsive, they will be advised of the non-conforming elements of the site, and asked to provide a remediation plan and schedule to resolve the issues, and may be asked to immediately modify or take the site down in the interim. In this remediation, GSD Web staff can provide strategic guidance and technical oversight, but all costs associated with bringing the site into conformity will be borne by the site owner.
- Site Owner/Sponsor: GSD faculty or administrator responsible for the website and its content. Responsible for goal setting, strategy & quality assurance; managing funding to support development & maintenance, oversee continuity through personnel (staff/student/developer/consultant) turnover.
- Content Editor: Individual with access to the backend of the site and responsible for editing and updating content and other settings.
- Site Developer/Technical Contact: Individual or group involved in the build out of the site, including theming and other customizations. Technical contact for errors, upgrades, and other issues.
- Every GSD subsite must have a Site Owner, designated Content Editor and a Technical Contact on record with GSD Web Staff, in addition to documentation including hosting details and passwords for emergency access.
Current GSD faculty and administrators may request a GSD subdomain name (e.g., mysite.gsd.harvard.edu or research.gsd.harvard.edu/mysite) for a website related to a GSD-affiliated research center, lab, program, or initiative.
A vanity domain name (e.g., “mysite.com” or “mysite.org”) may be used as an alias. Upon request and availability, GSD Web Staff will purchase a vanity domain on your behalf, set up the Domain Name System (DNS), and bill your group or department for the cost of the domain annually.
A GSD subdomain name may not be used for personal sites or portfolios. Individual students and faculty wishing to use a harvard.edu domain for personal use should request an Open Scholar site from Harvard Web Publishing.
To request a GSD subdomain name, site owners should fill out the New Site Information Form.
Harvard University Subdomains
All Harvard domains are managed by Harvard University Information Technology (HUIT). The GSD requests domain names from HUIT and is subject to HUIT’s workflow and approval processes. Although requests are often processed quickly, please allow at least several business days for domain name changes.
Student groups may not use a GSD subdomain name and must purchase their own domain name (e.g., mystudentgroup.org) through a domain registrar (e.g., aws.amazon.com). Note that student groups must obtain advance permission to use any form of “Harvard” or “GSD” in an internet address. Student Groups should contact the Office of Student Affairs to request permission.
A Harvard subdomain name (e.g., “mysite.harvard.edu”) may be requested for websites sponsored by inter-school groups and programs. Please contact GSD Web Staff for assistance requesting a Harvard domain name.
Sites authorized to use a GSD subdomain name must be on the WordPress platform. These sites will be hosted on a GSD subdomain managed by the GSD’s Web Staff. Only WordPress-compatible software will be supported (i.e., installed, updated, maintained, or hosted).
We have partnered with a third-party vendor to provide basic system administration and support for subsites hosted under the GSD’s domain name. Web hosting accounts are managed by the GSD’s Web Staff. Any associated costs will be billed directly to the requesting group or department.
External consultants or vendors may be given access to site administration tools by requesting Person of Interest (POI) status from Harvard University Information Technology (HUIT).
For some special purposes, WordPress may not be a satisfactory medium for web design or hosting. In the rare event that an authorized GSD subsite requires a CMS other than WordPress, it may be permitted only by consent from the Digital Governance Committee. Such consent will be granted only in extraordinary circumstances, where the GSD’s existing technologies do not adequately meet the needs of a project that has been determined to be worth the costs to the school of engaging new technologies to enable it. In such a situation, the site owner must agree to bear all costs of ensuring the new site is otherwise continuously compliant with this policy and all costs related to ongoing maintenance of the site.
All GSD websites must comply with Harvard University’s Information Security Policy. Confidential information may require authentication via Harvard Key or other conditions. Please review the following policies:
- Harvard University – Information Security
- Harvard University Information Technology – Information Security Site
- Harvard University Information Technology – Security Policy
All GSD websites and applications must comply with Harvard University’s Accessibility Policy. Site owners must incorporate accessibility into their development roadmap whenever applications are scheduled for a minor or major upgrade. Developers and content creators must unit test their code and/or content for accessibility. In addition, accessibility testing should occur as part of the test environment to stage environment deployment process. Any accessibility issues identified must be remediated before the application can move to production.
Vendor contracts for web/application development or hosting must conform to WCAG 2.1, Level AA guidelines and include the Accessibility Rider (OGC Model Documents webpage).
It is expected that any accessibility issues identified through testing or end user feedback ordinarily will be fixed within 12 months. For complete requirements, please view:
- Harvard University Information Technology (HUIT) Accessibility Policy
- Harvard Web Publishing Accessibility Guidelines (requires HarvardKey)
- Harvard University Information Technology (HUIT) Disability Services – Online Accessibility
- For requirements related to the development of mobile applications, see Harvard Web Publishing Mobile Technologies Guidelines (Requires Harvard Key)
Digital accessibility must be monitored throughout the life of a subsite. HUIT offers all “Harvard employees working on public-facing websites for Harvard” access to Site Improve, an online accessibility tool that provide reports on WCAG 2.1 compliance. Site owners should request access to Site Improve through HUIT so they can continue to audit and maintain their site’s compliance.
For high-profile subsites, the GSD reserves the right to require the Site Owner to hire a professional web designer for the project. This will ensure the site meets design, usability, and accessibility standards.
Even when hiring an outside designer, Site Owners may use the free GSD Site Builder platform to build their site. This will be a much cheaper alternative to building the site from scratch.
It is the responsibility of the Site Owner to ensure that content is fresh, accurate, and up to date; complies with University guidelines for Information Security and Accessibility; and follows University guidelines for media capture and usage:
- Photography & Video of Harvard Buildings & Facilities
- Media Relations Policies
- Copyright and Fair Use: A Guide for the Harvard Community
Content editors are expected to ensure that all links are live, tested, and appropriately implemented.
To prevent the dissemination of conflicting information, subsites must not duplicate official school information. Rather, they should link to the authoritative source. Official school information includes but is not limited to:
- Tuition, fees, and scholarship information
- Academic requirements
- Academic calendars and deadlines
- Course descriptions and schedules
- GSD’s mission statement, community values, policies and procedures, etc.
Please consult with the Office of Communications for guidance.
It is the responsibility of the Site Owner of any GSD website to ensure that all technical details of web hosting, including credentials for administrative access, are provided to GSD Web Staff, to enable ordinary administrative access for maintenance and otherwise as required.
It is also the responsibility of the Site Owner to ensure the site is in good working order, including performing regular software updates, testing the site after updates, ensuring working backups of the site and its data, and reporting errors to an external vendor or GSD Web Staff. All subsites must comply with University guidelines for Information Security and Accessibility.
Decommissioning and Archiving
GSD Web Staff review all subsites annually. Any site that has not been updated in 12 months will be scheduled for decommissioning. A good faith effort will be made to contact the last known Site Owner. If the Site Owner cannot be reached, the site will be made non-editable for one calendar year, after which the site will be taken offline. To request decommissioning of a subsite, the Site Owner should contact GSD Web Staff.
Decommissioned sites are not automatically archived but may be eligible for archiving by Harvard Library. Site administrators wishing to request archiving of a site should contact the GSD’s Digital Archivist.
5. Social Media
Individual programs or groups wishing to establish a social media presence should contact the Office of Communications for assistance. All social media sites bearing the Harvard or GSD name must comply with guidelines set forth by the Provost’s office, review Harvard Public Affairs & Communications’ Social Media Guidelines, and owners of such social media accounts are encouraged to complete a short training module about those guidelines.
Social media sites must be accessible by the Office of Communications for auditing purposes and will be subject to regular review. Vulnerabilities identified shall be remediated by the channel owner in a timely fashion. It is the responsibility of the channel owner to ensure accounts are in good standing and that all content complies with University guidelines for media capture and usage:
- Photography & Video of Harvard Buildings & Facilities
- Media Relations Policies
- Copyright and Fair Use: A Guide for the Harvard Community
- Social Media Accessibility Best Practices
6. Emergency Action
The Digital Governance Committee (DGC) may at any time require immediate action to change or remove any element of any GSD website, social media posting, or other digital communication. In such a case, if a good-faith effort to contact the site owner cannot be accomplished in sufficient time, in the judgment of the DGC, GSD Web Staff and Office of Communications staff are authorized to take all technical and other steps necessary to try to implement the necessary change. GSD Web Staff and the Office of Communications are at all times authorized to take any steps necessary to protect the integrity of the GSD’s web presence or the school’s reputation, without DGC approval.