Over the years, we have learned a lot while working with higher education institutions. We've compiled 12 tips for you to consider during your own development/design process with Drupal.
For the purpose of this article, we anticipate that your team is in the early stage of planning a platform move or upgrade on Drupal. We'll discuss who to bring onto the redesign committee, guidelines, goal-setting, the minimum viable product, how to structure your content, categories and taxonomies, success metrics, the RFP, the vendor review, kickoff, the plan for migrations, and how to handle the buildout process, from feedback cycles through launch.
1) Bring together the core team for this redesign
While your IT department may be materially responsible for the website conversion, the redesign benefits from a core group of individuals who provide governance and structure to the buildout process. This group is responsible for a variety of tasks: uncovering content, defining infrastructure, gathering stakeholder input, understanding success metrics, and deploying internal resources or hiring an external vendor.
The core team frequently includes diverse team members from across the organization. Someone in an IT or technical leadership role may spearhead the project, but you'll probably also have contributors such as designers, marketing communication representatives, web content editors, publication editors, development or major gifts officers, and department heads.
Typically, this team spearheads the overall effort to both solicit advice, opinions, and feedback from the overall university community, as well as communicate outward the “why” for the redesign process and any expected timelines. This team will also determine what constitutes success for the project. Bringing together individuals from diverse backgrounds helps to ensure a thoroughly-vetted outcome.
2) Establish guidelines for working together
Core team members who schedule regular meetings via conference calls (Zoom, Google Hangouts, and Uberconference all work well) and share a set of planning documents have a better and more-informed flow. A Google Drive file, Dropbox note, SharePoint document, or other multi-author documentation tool helps with note-taking, sharing objectives, and communicating the next steps.
The team begins the process of identifying the who, what, where, when, and how of the redesign. Meetings held once or twice a month should suffice. As the process moves forward, meetings become more frequent (2-3 times a week) during buildout.
It’s important to determine, in advance, the matrix of decision-making authority. When project roles aren't clearly defined, you may find yourselves in situations where everyone tries to be the decision-maker, or no one has authority to be the decision-maker. Once project roles are identified, the web liaison who will communicate team decisions to the vendor should be determined. Who has ultimate ownership over which piece of the project? Who has the final say? Document this in advance, and stick to established guidelines.
John Rearick, of Iowa State University, shared some feedback from experience developing on D8:
It's good to note that this part can be quite difficult, and can evolve over time. We work mostly in Jira or some other project management software and if there's conflict or ambiguity on a decisions, we put together decisions documents. We record our meetings, and notes are taken collaboratively in a boxnote (or google doc, or whatever) and are copied into a JIRA issue for the meeting. Afterwards, people should be taking the notes and discussions and update other tickets or create tickets based on those decisions and discussions. Depending on the size of the group, there could be different meetings for different areas. Not everyone needs to go to every meeting, but having at least one meeting per sprint with everyone helps with keeping everyone in sync.
3) Understand and align on goals
The process of re-platforming takes place only when the pain of staying outweighs the pain of changing. When initiating your new development, you’ve already surfaced the most painful points: security issues, bottlenecks in publishing, loss of credibility because of outdated design, or other factors. These pain points are probably what pushed your stakeholders to take action.
During the planning process, identify stakeholders, budget-holders, and approvers, and coalesce around bullet points to determine what the team hopes to achieve with this redesign.
What constitutes a successful redesign (example):
-
Fresh, modern, clean, 21st-century design
-
Mobile-friendly/mobile-responsive
-
Straightforward navigation
-
Call to Action on every page
-
Editors can easily publish new content
-
New users are easily managed
-
Seamless integration with donations, planned giving, alumni outreach, social media, mailing list, and other engagement tools
-
An attempt by other organizations to deprecate outdated technology in favor of the new content management system
Prioritize what the overall goals for this project include. When stakeholders provide input and understand the stated goals, it is easier to communicate and be aligned. Publishing them in a prominent place helps everyone stay on track during the next 3 to 12 months.
4) Define the minimum viable product
The minimum viable product (MVP) will be the first iteration of the redesign. When preparing the MVP, some projects may benefit from focus groups or guided sessions to determine priorities. To define the MVP:
1) Build out a list that determines overall needs.
2) Assign a priority level (or another mechanism for sorting the importance of what goes into the first version and what gets added in later phases).
3) Gain approval and clarity from all stakeholders.
Your development vendor can give you insight into what types of features may be implemented within a specific timeline and budget.
Without a prioritized list for the MVP, a project will get caught in an endless development cycle and potentially experience developer and managing-committee burnout. By creating a full list, and agreeing internally on what is required for launch versus what will be completed post-launch, all parties can align on what is to be put on the final deliverables list. Use either of the following as a starting point.
A feature request list might look like this, with every type of content listed out, sorted by priority:
| FEATURE REQUEST | Priority 1 | Priority 2 | Priority 3 |
|---|---|---|---|
| Editors may submit articles aka blog posts | X | No | No |
| Editors may edit content | X | No | No |
| Department staff (besides editors) may submit an article | No | X | No |
| Department staff (besides editors) may view unpublished articles | No | X | No |
| Flag an article as being “approved by managing editor” | No | X | No |
| Unpublish after a fixed amount of time | No | No | X |
Alternately, here’s another way of organizing information, sorted by priority for every content type:
For articles (also known as blog posts):
| Priority Level | Tasks |
|---|---|
| MUST HAVE |
|
| NICE TO HAVE |
|
| WISH LIST/AFTER LAUNCH |
|
| NOT SURE / NEEDS REVIEW |
|
5) Identify user roles, permissions, and content types
Drupal consists of many entity types. The most common are content types, which are fieldable entities that hold all the information relevant to that content.
Users with administrative privileges manage the content type itself. For example, this might consist of adding a new Image field to an Article content type or adding a YouTube Video field to that same Article content type.
Users with the correct permissions may also add new content, edit existing content, and delete content. Spelled out, these permissions might look something like this:
- Staff member Jody Nguyen may submit an article.
- Staff editor Janice Diaz may edit all available articles.
- Department staffer Ramesh Srinivasan may review unpublished articles.
Determination of roles and permissions begins during the planning phase. Determine what types of editorial processes already exist, and use what you want to keep as a jumping-off point.
Here are some examples of roles and permissions to help guide your thinking:
-
A non-logged-in (Anonymous or Guest) user may read published blog posts.
-
A logged-in user with the role of Content Editor may create and edit blog posts and also view unpublished blog posts.
-
A logged-in user with the role of Department Chair may edit the Department description.
-
A logged-in user with the role of Staffer may leave comments on blog posts.
-
A user with multiple roles will be able to do all functions assigned to their roles.
And these are some examples of content types we’ve implemented across .edu spaces:
Pages
Pages such as an About page or a Privacy Policy are typically evergreen and may contain:
- Title
- Image
- Author
- Body/Description Text
- File Attachment/s (i.e. PDF files)
Articles
Also frequently referred to as blog posts, articles commonly contain these fields:
- Title
- Image
- Author
- Byline (sometimes, for example, there are multiple attributed contributors)
- Body/Description Text
- File Attachment/s
Department
For example, the Dept. of Computer Science, or the Student Affairs Division; departments may include:
- Title
- Body/Description Text
- Image
- Main contact information
- Chair
- Faculty/Staff (pulls from a defined list of people)
Person
For example, a professor, adjunct faculty, or administrative supporter; person content types might contain:
- Name
- Image
- Bio/Description Text
- Academic achievements
- Papers, reports, publications
Event
For example, seminars or talks open to the public; event content types may include:
- Title of Event
- Image
- Start Date
- End Date
- All-Day Event
- Description
- Weblink, i.e. for registration signup
As you work through the process of identifying user roles, permissions, and content types, you’ll hone into more detail on a per-field basis. You'll consider things like the characteristics of that field, required vs. optional, who is allowed to edit that field, and who is allowed to view.
Example: Events
Events: Our university offers ongoing scheduled events, which include seminars, social gatherings, and talks open to the public. Our development offers an “Open to the Public” discussion Question-and-Answer series of events. Some of those are targeted to Alumni. Some of our events require an RSVP, and some also require payment in advance.
- Title of Event: this has a character limit of 255 characters.
- Image: upload an image, or choose from a library of available images.
Determine height, width, or size restrictions, as well as any style guidelines. - Start Date/Time: Choose from a list where the user picks from a calendar.
This is a required field.
The default is two hours from the moment the editor creates the event.
Start time is required. - End Date/Time: Choose from a list where the user picks from a calendar, not required.
Default to a date that is three hours after the start date. - All-Day Event: Checkbox
- Description: Need the ability to add a description using a WYSIWYG editor.
Need to be able to paste from Word. - Weblink for registration: This may be a link to an off-site registration page, like Eventbrite or SplashThat.
Multiple links are needed. - Other notes: Need to specify if an event is recurring.
Need the ability to offer multiple start dates/times.
Need to close reservations after X number of people sign up.
Some events should be tagged as “Open to Alumni.”
Only Calendar Editors are allowed to create a new event.
As your team identifies relevant content types, determine and document how content is used in relation to other types of content.
Example: content type relationships
-
Department might offer a list of Faculty (Persons), sorted alphabetically by last name.
-
Department might similarly link to a list of relevant Articles or blog posts.
-
Department might add a list of upcoming Events.
-
Article might link a referenced upcoming Event.
Mark up, in as much detail as possible, the relationships between content, and the opportunities to repurpose fields. Think about whether it’s possible to collapse multiple fields so that, for example, just one Image field may be utilized across all content types.
It’s also important at this stage to put some thought into the level of access to create, edit, and delete content. This is where you define user roles and permissions. You may build on existing policies that govern access to content.
Example: Roles and Permissions
| Anonymous, or Guest | Authenticated | Department Head | Staff | Content Editor | Admin | Superadmin | |
|---|---|---|---|---|---|---|---|
| Create a blog post | No | No | X | X | X | X | X |
| Edit own blog post | No | No | X | X | X | X | X |
| Edit any blog post | No | No | No | No | X | X | X |
| Delete own blog post | No | No | No | No | No | No | X |
| Delete any blog post | No | No | No | No | No | No | X |
| Add a department | No | No | No | No | No | X | X |
| Edit own department | No | No | X | No | No | X | X |
| Edit any department | No | No | No | No | No | X | X |
| Delete own department | No | No | No | No | No | No | X |
| Delete any department | No | No | No | No | No | No | X |
| Use the general contact form | X | X | X | X | X | X | X |
| Submit a comment | X | X | X | X | X | X | |
| Read submitted comments | No | No | X | X | X | X | X |
6) Determine categories and classifications
Categorization (called “taxonomies” in Drupal) helps classify content.
Some real-world examples include:
-
An “Event” might be classified as being: Private, Public, Requires Registration, and/or Online-Only.
-
A “Person” might be a tenured faculty member, adjunct faculty, support staff member, or work-study student. A person may be able to hold multiple categories at one time.
-
A “Building” might be sorted into categories like Athletic Use, Laboratory, Student Services, Medical/Health-related, Classroom, and/or Auditorium.
As you determine lists of categories, document them in your shared documents and circulate with the wider team to clarify assumptions and narrow down the details.
| Event Types | Person Types (pick multiple, maximum 2) |
Building Types (pick multiple) |
|---|---|---|
| Private vs Public | Tenured | Athletic |
| Requires Payment | Faculty | Laboratory |
| Requires pre-registration | Adjunct | Student Services |
| Online-Only (Webinar) | Support/Administrative | Medical Health |
| Open to Alumni | Student | Classroom |
| Series 1 Series 2 Series 3 |
Work-study | Auditorium |
| Temporary |
7) Define success metrics
What is the aim of this website redesign?
How does the organization determine if the new website does a better job?
Think about stakeholders and their priorities, and organize success metrics around user needs.
Budget-holders typically approve metrics such as:
-
Quicker load time
-
Increase in audience engagement (sign-ups, donations)
-
Increase in unique visitors
-
Increase in time spent on the site
-
Improvements to mobile-responsiveness
-
Reduction in time to publishing new content
-
Improved workflow i.e. contact form goes to the correct person
Additional metrics we’ve experienced, such as with Carnegie-Mellon University, include:
- Existing sites and content can be moved from the legacy CMS or site
- Soliciting stakeholder and editorial user positive feedback via survey or evaluation
- Increase in stability and scalability
- A decrease in hosting or licensing costs
If you return back to your overall goals from the very beginning, you should be able to narrow down success metrics to match these goals.
8) Circulate the RFP - reach out to trusted providers
Find an agency that suits your needs with an RFP or RFQ that includes these details: overall goal, desired timeline, ideal budget, metrics of success, and a discussion of content types, user roles and permissions, as well as categories/classifications.
While nothing needs to be finalized yet, when you identify overall targets, you help narrow down the field of appropriate vendor partners.
These are some typical questions you might include in the RFP:
-
Company and team qualifications
-
Experience with similar projects
-
Strategy, design, and development expertise
-
Proposed timeline, budget, deliverables
-
Description of the project management process
-
Security process (the university security team may help vet this)
-
Accessibility process and integration, including examples of past accessible sites
-
Migration planning
-
Support and maintenance options
-
Hosting options
9) Vetting and review of vendor proposals
Typically your committee determines a scoring mechanism ( i.e. 10 points allocated to the team, 10 points allocated to approach, 10 points allocated to prior experience) to help teammates rank incoming proposals. A couple of notes when vetting vendor proposals:
- It’s helpful to create a shortlist prior to asking for generalized feedback from the wider team.
- It’s helpful to have all scorers read all shortlisted proposals to assign a fair ranking.
- Consider breaking down the process into rounds with an ability to choose from:
- A semi-finalist round of (6 to 10 firms)
- A finalist round (3 to 5 firms) with an option to make presentations
- A final selection and review process
By going through a transparent, documented process, the team continues to refine and gain insight into which vendor best fits the organization’s unique setup and personality.
Think of your vendor as an engagement partner who will do their best, based on their knowledge and understanding of the project, to deliver the final product inside time, budget, and quality constraints, and who brings all their experience to the engagement in order to uncover efficiencies and yield high value.
10) Kickoff - ensuring a successful start
Upon signing agreements and developing a statement of work and deliverables, the kickoff approaches!
Identify the following: key team members, the overall schedule including scrum or check-in meetings, liaisons/decision-makers/budget or sign-off approvers, and acceptance criteria for each phase such as discovery, design, development of the pilot, site migration, and launch.
11) Plan for migrations
Consider the resources, budget, and timeline required for migrating existing sites. This may have to be addressed as a separate stream of work, as both migrations and hosting changes are nearly inevitable, and frequently blindside projects with their complexity and time requirements.
For hosting, consider your hosting options and whether there’s an option to host outside of the organization. We recommend a managed host such as Pantheon, which has a stack that is fine-tuned for Drupal, includes multiple cache layers and offers redundancy and enterprise workflows for development, testing, and production.
12) Buildout
Communication with your project manager ensures success during the buildout phase.
Be in touch with your project manager and account manager as frequently as needed. Insist on scheduling sync meetings, typically two to three brief check-ins per week to report on progress, identify blockers, and clarify the next steps. Tools such as Jira, Bitbucket, Trello, ActiveCollab or GitHub issues are a way to surface items and be informed of ongoing needs. Lullabot has written articles on managing projects with GitHub here and here.
Some groups may be dealing with existing sites and supporting a legacy platform, while simultaneously developing the new site. It’s always a balance for the points of the engineering triangle: Fast, Cheap, Quality, pick two. There's a balance between speedy development, inexpensive costs, and high quality, and your team may need to prioritize two of those.
The typical agile process proceeds in two-week sprints around specific feature request areas, with demonstrations and team syncs to ask questions and make sure stakeholders reach agreement and sign-off.
The feedback cycle
Use feedback loops to ensure adequate responses on a regular basis. By using a tool like Tugboat.QA, the team helps improve communication by getting feedback earlier, instead of waiting for bi-weekly or monthly sprint demos.
Most .edu sites have strict branding guides, so when making decisions, it’s important to adhere to those guidelines. Having styling and brand guides available at all times, in a shared format with everyone on the committee and team, will help resolve any conflicts in decisions over the look-and-feel of certain elements.
As a structural factor, the site must abide by accessibility requirements. In many projects, it can sometimes be a balancing act between the look and feel of a site and its accessibility, such as higher-contrast colors, underline links, and using headings correctly.
A successful launch relies on your team responding on a regular basis, surfacing issues as they arise, and answering questions when prompted. Depending on the complexity of the code rollout, within 3 to 12 months you’ll have an updated, easier-to-use, refreshed website that’s mobile-responsive, attractive, and makes a measurable difference for your campus success.
Learn more from our higher ed case studies, including NYU School of Medicine, Carnegie Mellon University, and Harvard University; or learn about our Support and Maintenance services.
I would like to thank Nate Lampton and David Burns for providing thoughtful feedback on earlier drafts of this article, and also many thanks to John Rearick and JT McHorse for additional edits.