On-Demand Webinar icon On-Demand Webinar

8 Technical Questions to Ask Before Building a Website

If you’re thinking about upgrading your website in the next few years, this session will save you time, money, and headaches. After 20+ years of helping organizations of all sizes design and build websites, we have identified eight common pitfalls that you may not have considered—oversights or misunderstandings that can sink a website redesign. Sidestepping these challenges now, before you’ve even begun, will make your entire website project more successful and—dare we say it?—fun.

In this webinar, we’ll explore each of the eight questions you should answer to keep your sanity and budget in line. Questions like:

  • What third-party systems do we need to integrate with?
  • How much content needs to be migrated?
  • Where does my DNS live?

By the end, you’ll be able to:

  • Ask the right questions (and know which answers to look for)
  • Work with your IT team to set reasonable expectations
  • Audit your current website and technology to define the scope of your website project

Transcript

Rachel: Welcome to “8 Technical Questions to Ask Before Building a New Website.” So we are getting technical today. It’s right there in the title. We’re going to walk through these technical questions and we may include terms you don’t understand, and in fact, that’s sort of my role today. So I’m a communicator, a marketer. I am not a technical guru. I like to think that I dabble in tech, and Stephen can probably agree to that. So my role, as we move through the webinar, is if we get into the weeds on this sort of technical stuff, I’m here to sort of pull Stephen out and say, hey, can you explain that a little bit better, for those of us that aren’t technical. And one thing we know from working on countless websites is that a lot of times, people are not thinking about the technical questions upfront, so that’s why we’re going to do this today.

 

I’m going to kick off our poll. And the question is, “are you considering a website redesign?” So you’ve got a few options here. Stephen, did you manage to get the poll launched?

 

Stephen: I can.

 

Rachel: Okay, thank you. So a couple of options here. One is going to be, yes, we’re considering a website webinar— sorry— website redesign this year. Yes, but not this year. No. And then we added the last one, I want to but there’s no budget/leadership buy-in. Because we see this all the time, so don’t feel guilty if you have to accept that. And that is totally expected.

 

So what we’re seeing is, yes, people are redesigning this year, which is great. We have really seen our digital needs increase as people have moved online with COVID especially, so that’s great news. What I don’t want you to do, whether or not you are thinking about a redesign, I don’t want you to say, “just give me a website.” That’s not what we’re looking for. So we want you to really think through why people need— or why you might be needing to redesign your site. So has it— sorry, I’m closing that poll. Has it stopped working for you? Is it hard to manage? Is it outdated? Is it not serving an organizational need anymore?

 

A lot of times, people kind of just know they need a site and they haven’t really thought of the depths to which they might need it and what that might look like. And so we want you to think about, if you had a relative come to you and say, “build me a sandwich.” Now, this an eccentric and rich relative, so they’re going to pay you a million dollars to build them the perfect sandwich, so you’re excited right now to build this sandwich for this crazy relative. And you start to pull out your bread and you start thinking about all the options that could be in this sandwich, and maybe you don’t know a whole lot about this relative. Like, are they a sandwich eater— sorry— a meat eater? Are they a vegetarian? Maybe they’re a vegan? Do you create something really simple with great ingredients or do you go all out? Does this relative like mustard, spicy mustard, brown mustard, plain mustard, no mustard? Should you cut the sandwich when all is done? Should you make it look fancy and add a little garnish to it?

 

And so you do your best job, and at the end of the day, you don’t really know if you appropriately built this sandwich to meet your relative’s needs, and so a website is very similar. That’s just to sort of illustrate the idea that it can be designed and built in a million different ways. So there’s lots of choices, both big and small, that will influence the long-term success of your site. And so our questions today are really to get us thinking about how to make sure that what we’re building is successful for us from the very outset of our project.

 

I’ll give you an example, a website example. So, say you have a simple form and you want to get people to volunteer for your organization. So you think, okay, this form is pretty simple. But then you start thinking about it a little bit more and you start asking questions like, well, where does this form exist on our site? Is it a single-page experience or a multiple-page experience? What happens when the form is submitted? Does it go into a database? Is it aligned with my CRM or my AMS? Who gets notified that the form has been submitted? Is it one person? Is it routed to a group? How is the information that was submitted secured? And then what kind of autoresponder does this person get when they have submitted the form? So as you can see, there’s just a sampling of questions when you’re thinking about a simple form. It’s never as simple as we want it to be. So over the years, we’ve begun to really refine the technical questions that we’re asking and we want to give those to you today so that you are set up for success.

 

I’m Rachel Clemens. I am the Chief Marketing Officer here at Mighty Citizen. I have 20 years of experience on the marcomm side of things, so again, not a tech person necessarily. Stephen and I agreed— this was my idea. Now I’m kind of regretting it because his is way cooler than mine. We agreed we would share one thing that was kind of unique about us. And so I have actually been bitten by a zebra. I still have the scar. It’s been a while, but I can prove it. It was at one of those safari parks, so highly fun, maybe dangerous. If you’re not familiar with Mighty Citizen, we’re the branding, marketing, and digital agency for mission-driven organizations. So that basically means we help our clients increase their revenue and improve their communities through things like websites, messaging, campaigns, research, analytics, anything and everything related to technology and communications.

I’m joined by Stephen who is our tech guru. And, Stephen, would you like to introduce yourself?

 

Stephen: Yes, thank you. Hi, everyone. So, my name is Stephen Tidmore, as Rachel said. I’m the VP of Technology here at Mighty Citizen. I’ve been working on technical projects and web projects for about 20 years. I’m also a certified professional in accessibility core competencies. And my interesting fact is that I’m a former Elvis impersonator. So I’ve been involved with a lot of web projects over the years, a whole lot, and one of the benefits of being involved in so many web projects is that I’ve also seen a number of ways that those projects can go wrong. So the benefit of that is that I’ve become much better about knowing what questions I can ask upfront in order to avoid some of the pitfalls that I’ve seen those projects fall into.

 

Today, as Rachel said, we’re going to explore some of the most common tech issues we see when beginning a new web project. We’ll discuss some processes like content migration, CMS requirements,

single sign-on, and a lot of other things in between. And our hope is that you’ll be getting an understanding of what questions we ask before we get too far along in the website redesign or rebuilding process. And then these are questions you can then ask when you’re thinking about starting a new web project.

 

So, my goal for the presentation today is really to explore some of the most common tech issues we see. You’ll start to think through some of the questions that will help make the website process more efficient. We’ll cover a number of questions that we ask internal IT teams in order to understand some of the technical requirements for a project. And you’ll learn how to evaluate the tools you need to work with and what tools you’ll need to meet your organizational goals because that’s the most important part of any website project is to meet your organizational goals. And then ultimately, the goal is that you’ll be able to start creating a list of the requirements for your new website. I also just want to say that there are a large number of other questions we ask at the beginning of a project, a web project that are more focused on things like information architecture, visual design, content strategy, marketing, and analytics. The list goes on and on. So like Rachel said, the ones we’re discussing here today are related mostly to technology that we would be working with for that web project. So again, this is not an exhaustive list of all questions we would ever ask. It’s just some of the most important tech ones.

 

Rachel: Stephen, I wanted to add here, because I forgot to mention, I think that we do have a lot of communications people on the call because ultimately, a website is your responsibility, so you will have to work with your tech teams, whether that’s an internal tech team or an outsource partner. We’re going to go through these questions and you’re going to think, I don’t know the answer to some of these questions, and that is totally expected. Just like Stephen and I partnered up on our site, you will have to partner up with the tech teams.

 

Stephen: Yeah, definitely. Some of these questions are maybe a little less technical and related to content and things you may be more familiar with, and some of them are probably things you’ll have to go to either your IT firm or your web host or something like that to figure out.

 

So we’re going to jump in. We’re gonna start off with a big one and this one is content migration. So content migration is often one of those things that people just assume is going to happen seamlessly when you’re starting a new website that will take the place of an existing website. But in my experience, it’s rarely seamless, and sometimes, trying to migrate all that content may actually be hurting you more than helping. The big consideration is you don’t want to limit yourself in the architecture and design phases of your project on the new site by forcing the content to match up with what you currently have on the existing site. So the big question is, do we need to migrate content, and if so, what content?

 

There is a common misconception that everything on your existing website will have a home on the new website, and that’s not necessarily the case. Some of your content may not be relevant in your restructured website and it also may not realign with the newly architected and designed pages. You can’t count on everything having a one-to-one fit. It can be a square peg, round hole situation, or sometimes no hole. So for example, let’s say your current website mostly consists of one large WYSIWYG field for each page. And a WYSIWYG field is something you’re probably familiar with if you’re used to editing any website that uses a CMS. It’s kind of like Microsoft Word or something where it’s formatted and you can bold text, and add lists, and that kind of thing.

 

However, on your new website, there may be a lot of structured data. So for example, if the team member pages, maybe those team member pages now on the new website have custom fields for their name, their job title, their phone number, their email address, maybe a categorized list of the departments they work under. And if that content was all just contained in a single WYSIWYG field on your old site, kind of a big blurb of HTML, then you need to figure out what process you’re gonna have to go through to get that data into structured fields. Is it worth it to figure that out and build it into some kind of migration script? Or are there only 20 pages and manually copying that content into the new site would actually take much less time? Is it even possible to write logic around getting the data into the new fields? Sometimes, I’ve worked on projects where it isn’t possible because there’s no logic around where the data exists on the current site and there’s no structure at all.

 

There are, of course, times where it does make sense to auto-import your existing content. We see this a lot with things that are already structured, like press releases, blog articles, events, any kind of content that already has structure. However, usually, there are new pieces of content that need to be added after the import based on the requirements for the new website, which brings us to the next question, is new data. Will each migrated piece of content or page need to have new pieces of data added after that migration? For example, if you had an event calendar on your old site and you have an event calendar on your new site, maybe the new site includes filtering based on categories that didn’t exist on the previous website. So someone has to go through and assign all those categories to each event, which may not be a big deal if there aren’t a lot, but if you’re trying to go back to all the past events and you have hundreds and hundreds of these, it can be a big project. So who will handle that process if you need to do it? Do you have someone available to spend the time adding in those new pieces of content once the original content has been migrated, or is that something you’re going to want to outsource to an agency like us or someone else?

 

After you run the migration, you also need to think about broken data or maybe some old styles that migrated with that data. The URL structure will most likely change, which means that if you import content with hard-coded links in the HTML, all those links could be broken. So you’ll either need to fix every single broken link or hopefully be able to redirect all the old links to the new ones. Ideally, you would do both eventually. And if you do need data in all those redirects, you may or may not have enough structure with URL patterns from the old sites. So, for example, if every blog post was at /blog, /post, /something, then it may be easy to redirect those in bulk. But if there wasn’t a structure built into those URL patterns, then it can be really hard. You’d have to manually redirect for each of those. You also may need to deal with images or files. There may be image tags or links to files that are broken if the file— actual folder where those files live on the webserver changed during the migration or in the new site. So you need to make sure all of that media is handled properly during the migration.

Ideally, the migration process can take care of remapping all that data, but if that doesn’t happen as part of the migration process, then you’d have to take care of each field in every file.

 

Another thing we see often is inline CSS, and I’ll explain that in a second. So, does the existing content have inline CSS? And if you’re not familiar with what CSS is, it basically gives you all the styles on your website. It’s way deeper than that, but styles is how you can think of it, the look and feel. And inline CSS is where you can actually add code into the HTML of a page that just says— and you wrap it around like in a little section— you say, okay, this section of this text, I want to look like this instead of whatever the rest of the text looks like across the site. I see that happen sometimes on old sites where content admins may have had free reign in a WYSIWYG field or something like that and they can just end up editing the HTML to get it to look however they want regardless of whether or not it matches the existing site styles. So if that exists and that all comes over in the migration, then that has got to override the styles for the text on the new site as well, and so it would not end up not matching the look and feel of the new site. So we’ve had to go in and strip out all the inline CSS previously as part of a migration process, so something you need to be aware of for sure. Okay, we’re going to have one more poll here.

 

Rachel: Yes. Hold on one sec there, Stephen. I want to make sure I get the right one. Here we go. The question is, “were you with the organization when the current site was built?” I added a— I won’t admit to it because a lot of times, people are sort of like, oh, yes. But, you know, things grow, including websites. So let me— I’m going to end the results here, or end the poll, and share the results. And I want to add, while people are looking at that, I can tell you from working on websites for 20 years, the content part is the hardest part. It’s the part where the agency you might have outsourced to needs you the most because you have the knowledge from having been there if you were there previously. And it’s the place where a lot of times, the team, the organization who’s getting the new website, that they’re responsible for some new components of the website. And so this is where we started with a doozy. I hope you’re hanging in there with us, but the content is really where a lot of times things get tough.

 

Okay, so our results are most people were not there when the current site was built and a few of you were and were involved. But nobody said I want to admit— oh, one person said, I want to admit to it, so that’s pretty good. That’s pretty good odds.

 

Stephen: It’s a safe space.

 

Rachel: Safe space. Stephen, I think you can move on. There you go.

 

Stephen: Yup, got it. I had to close the poll. So that leads us to this question. Does someone in your organization now truly understand the structure and the meaning of the content on the current website that you need to migrate? In other words, does someone fully grasp how and why the current data was set up the way it was and the needs that it met when it was set up like that? There’s a high probability that people involved in the content migration might not have a thorough grasp of the structure and the meaning of the source data. And as we just saw in that poll, a majority of the people who are attending this were not there when the current website was built, so you might not have the history of why the content was set up the way it was.

 

This can lead to a loss of information or it can come at a very high cost of time and money for people to get up to speed on the historical data structure. We’ve worked on a lot of projects like this where it takes us a long time to understand the historical data enough to even make recommendations on how to migrate that data. And if we’re working with a client who really doesn’t understand this structure, then basically they’ll have to pay us to figure it out for them and spend more money than they might have allocated in their budget. Or they need to do a lot of upfront work on their side to figure out, you know, why the content exists in the structure that it does. Okay, so that was content. As Rachel said, that’s a big one.

 

And we’re going to jump to the second question, which is, where will the new site be hosted? So hosting is obviously very important for any new website because if you don’t have hosting, you don’t have a website that people can get to. So the first thing you need to do in order to figure out where the new site is going to be hosted is to figure out the specs, the specifications from your current website traffic, and hosting environment. And this is something where you may not have this information, but you’ll need to work with whoever has these details about your current hosting setup and your visitor analytics, so maybe Google Analytics or another tool like that, to get information about these things; your visitor analytics, the hard drive space, the RAM that’s used— and it’s okay if you don’t know what all these mean— the CPU, and the monthly bandwidth. And one of the most important things is that when you look at this data, you don’t want to take a snapshot in time. You need to take into account a kind of historical activity, both regular activity and during traffic spikes. Some organizations may have twice a year where something big happens, I don’t know, a conference, or maybe they know that a couple of times a year, there’s a controversial press release that they release or something, and traffic just spikes like crazy. You need to account for those things now, and so you have to look at all the historical data in order to kind of build a holistic picture of how many resources you’re using on your current website.

 

Rachel: Stephen, would you go to your hosting provider to provide the RAM and the CPU needs?

 

Stephen: Yes. Yeah, whoever is currently serving as your hosting provider should be able to provide everything on this except for the visitor analytics, which will be whoever is in charge of your analytics through Google Analytics or something like that.

 

Rachel: Perfect.

 

Stephen: So, once you have that information, then you want to figure out what your needs are for things like scalability, access, and support. So you want to make sure you have a hosting solution that provides enough bandwidth for additional traffic, which is kind of assuming your new website will attract more people. Hopefully it will attract more people. So you need to think about when you are going to scale up your hosting resources and how often. So scalability just basically allows you to increase the specifications and capabilities to fit your traffic needs. You can think of it as scalability is the same as you adding more resources to your computer or getting a new computer. You get a new computer that’s faster for whatever reason. So scalability in a hosting environment is very similar.

 

Auto-scaling is fantastic, and what that means is that it basically allows you to adjust the resources, the capabilities of your hosting environment so you’re not overpaying for something that you’re not going to use year-round. So, for example, let’s say an organization has steady traffic throughout most of the year, but kind of like I just said, maybe they release a controversial press release once or twice a year that causes a sudden influx of traffic. You don’t want to pay to host the amount of traffic that comes in in that influx the entire year. You ideally would only want to pay it during that one spike. And so auto-scaling is a great option because it allows you to scale up when needed versus paying a fixed amount to accommodate for that increased traffic throughout the entire year.

 

Also, you need to think about who is going to need access to the hosting environment and at what level. So when we think about things, like how are they going to need to get access to the server, there’s a couple of different ways you can access servers. And I’m not going to get into all the technical details now, but you need to think about that now. Like, do they need full access to the server, or can they just log in through something like SFTP into one little folder down to add files or something like that? You also need to think about if you’re going to only allow connections from a set of defined IP addresses. And what that means is if people are only allowed to log in to your server or into your content management system, maybe from certain locations, it’s a good security thing you could do. You need to think about firewalls and restrictions, kind of what sort of rules you want to put around this access. And that’s really kind of a security discussion that you want to have with someone who’s knowledgeable about that kind of stuff.

 

You want to find out if your host or whoever’s going to be hosting the website supports a modern development workflow. And what this means is typically a Git version control workflow. Git is a version control system that just gives developers a way for managing code and files for a website, more or less. And typically, modern web development is involved with Git and with deployments and pipelines, so there’s a lot of stuff that can happen automatically. We’re not literally just dragging files over into a server one by one. But you need to find out if the web host supports that modern development web flow. Or does your web host maybe require some weird workarounds, like using a dedicated laptop that’s given to you by the IT team that’s running those servers, and then you have to use that laptop to remote desktop into a server that’s in some kind of lockdown data center, and then that IT team expects you to write all your code through that remote desktop. This is something we’ve run into, and if that’s going to be the case, we need to find out about it now and hopefully make some plans to adjust that workflow. But if not, we need to account for all the extra time that it’s going to take to work on the server that way.

 

You also want to think about who’s supporting the hosting environment versus the website itself. If you’re going to work with a host that also expects you or your vendor, or whoever to be system administrators— that means people who actually maintain the servers themselves— then you need to know that up front. There can be conflict sometimes between an agency, such as ourselves, and a web host if there isn’t a discussion upfront around who is responsible for which pieces of the hosting environment and the actual application that runs the website. If you can go with a host that specializes in the content management system you’re using, whatever that is, all the better. There’s always a benefit to doing that.

 

The next thing you want to consider with web hosting is what sort of technologies is your web host able to support. Really, just the key here is you want to make sure you don’t get stuck with a host or a system administrator that only understands one technology if your website is built on a different technology. So the example I’m giving here is .NET versus PHP. So I’ve worked on projects like that where they have turned it over to system administrators who only understand .NET or building a PHP-based website, so you need to find that out now.

 

DNS hosting. Okay, so DNS hosting— if you don’t know what DNS is at all, at its most basic level, DNS is what controls where your domain name points. So when someone types in your domain name, what server does that point to, is kind of the core piece that we’re concerned about here. So when you launch a new website, you have to update the DNS record for your domain name to point to a new location on the new server.

 

And so you need to find out where your DNS zone is hosted. Where are those DNS records hosted? If you don’t know where this is if you have no clue, then typically, we’d want to start with where your domain name is registered, and you can typically find out the information through there. Sometimes, the DNS is hosted at the same place, sometimes it is not, but you can always start there and figure it out. This doesn’t really come into play until launch time because you don’t need to update the DNS records until launch typically. But we have had clients that aren’t sure where their DNS records are hosted or who they need to talk to in order to get those updated, and so we want to make sure we have this information well before launch so it doesn’t hold up any kind of launch timeline.

 

Rachel: Yeah, worst-case scenario is you’ve got a launch date, you’ve built a plan all around this new launch, and then you don’t know where the DNS’s are sending. You’ve got to go find it.

 

Stephen: Yeah, and we’ve worked on projects with clients who didn’t know or they thought they knew and they find out at launch day— they said they would handle it, and they find out on launch day that actually there’s one person who’s in Belgium and he’s the only person that has access to these DNS records and he’s on a different time zone and he’s on vacation. So you don’t want that to happen to you. You got to find that out well before launch. This is why we ask this question at the very beginning of every project. So that may be months and months and months before the website launches, but we want to make sure we’re aware of that early enough.

So, you also want to check and see if there’s any internal DNS server in your office. And the person who would have this information would be if you have an IT vendor or anyone internal IT in your office. I know that most people aren’t in offices these days, so it may not apply. But when you are back in your office, this may apply because we’ve had a number of clients that have IT setups that include internal DNS servers. And what that means is their computers, when you’re in the office, actually, look up the domain name records from that internal server as opposed to going out to the general World Wide Web where everyone else is. And so when we launch the site, the whole world can see it except for people inside their office if they don’t update those records as well.

 

Okay, question number three. And just a reminder, I know if you all are asking some questions, we’ll have time for questions at the end, so please feel free to ask away and we’ll get to them at the end.

So question number three is, how does content get published? So content is king. Even I admit that and I’m the technical guy. Content is the most important part of your website and should be a major consideration for your new website. So when you’re thinking about content publishing, you want to start with your organizational goals and your existing procedures for publishing content first. So, who’s going to be working with your content? What kind of permissions are they going to need? Is your content up-to-date and relevant right now on your website, and if it is not, why not? Is it because of some limitation in the content publishing process in your current CMS, or is it really an organizational or content governance issue? A lot of times, people like to blame the CMS, and sometimes, it’s very valid—like, the CMS may be very hard to work with. But other times, it’s really an organizational issue, like your content isn’t being updated because there’s not a process internally to get that content updated. So you want to think about that now as opposed to moving to any new CMS and then being stuck with the same issues where it’s an organizational issue, not a technical issue.

 

Do you really need to build an approval workflow into the CMS? So an approval workflow is a workflow where one person can go into your content management system and they could add it or they can edit or add content that’s combined into added content, but then that content won’t go live on the new website until someone with higher permissions actually logs in, and approves it, and publishes it.

 

So, workflow is one of those things that, for most organizations, seems desirable, but we’ve also had organizations that realized during the process that the person who is actually going to have to approve the content for publishing doesn’t want to log onto the CMS to do that. They want someone to email it to them and then they can just approve it and send back, hey, this looks good, or send back edits. So you don’t want to get stuck with or pay for a capability that you won’t utilize because then you have a bottleneck if you’ve built in this whole process and the person who has to approve is never going to login to approve. If you do need that publishing workflow capability, then you want to think about how many levels of approval do you need. Is it just an editor to a publisher or is it an editor that goes on to approval level one that goes to approval level two that goes to a legal approval that then goes to final approval and it gets published? That stuff can get really complicated, so you want to start mapping that out at the beginning.

 

You also want to think about the functionality or features that are required in your CMS. So you want to sit down with your team and dive deeper into your current site. Think about the following questions. Is your current CMS simple enough for non-technical staff to use? So sometimes, it’s not and that could really be the issue why content is not up-to-date. So if it’s not, then you want to start thinking about what you need to do to make sure that it is simple enough and what content are these people going to need to be able to control?

 

Rachel: Stephen, can I pop in here just to—

 

Stephen: Sure.

 

Rachel: Layman’s terms, CMS is content management system.

 

Stephen: Yes.

 

Rachel: Probably most people know that. But it is the technology that allows you to edit and create content that is going to be published on your website. So, examples are Drupal, Craft, WordPress, Sitecore, things like that.

 

Stephen: Yeah, Kentico. There’s tons. So, yes, thank you, Rachel. CMS is content management system and it’s the application that runs the content on your website and delivers it, so, yes. It’s where you usually log in to edit things on your site. So, does your current CMS or the CMS that you’re considering have an active community of developers that can offer support if needed? You want to make sure that there’s a wide variety of options out there for support. Can the CMS you’re thinking about be integrated with third-party things, such as your CRM, maybe if that’s a requirement, or a user database you have, or maybe any other third-party platform? And we’re going to talk about third-party platforms in a little bit, but just know for now this could be a big discussion. Third-party needs is a big discussion.

 

In addition, is your website actually furthering your goals in any way right now, and if not, what needs to work better? What goals can the CMS help with and which ones are really related to internal processes? Kind of like I talked about with content earlier. Something else you want to consider for sure upfront is, will there be a need for multilingual content now or in the future? If you think it’s going to be a need, you don’t want to get stuck with a content management system where that’s a painful process to manage multilingual content. There are a lot of other questions we consider when building a list of CMS requirements. I mean, just a few others are things like a need for modular content, which is pieces of content that you can add across the site wherever a desire may be for live previews, for content administrators. Maybe you need to get really granular crazy permissions where only this one person is able to edit this one field on an entry. That kind of stuff. So there’s a whole host of other questions, just to give you a taste, but the ones we’ve kind of mentioned here are some of the big ones we start with.

 

Rachel: Yeah, I want to add one thing about the CMS’s is that they—from a communicator’s point-of-view, like, your CMS can do just about anything within reason around— but you have to consider how much you actually need. So again, we’re trying to right-size our technology to our website. So think about all the things you wish it could do and then you’ll have to weigh that against how much your budget is and whether you’re putting undue process onto things that might actually slow you down. So a lot of things with the permissions based on individual fields, who has that permission? Do they actually want that permission? Again, if they want you to print something out and give it to them to hand-edit, that’s unnecessary. So I just want to pipe up to say that we’re trying to right-size our needs here.

 

Stephen: Yeah, that’s a really great point. Right-size is a great way to think about it because you can do almost anything on almost any platform that you want to, but sometimes that flexibility comes with a cost. Sometimes that cost is actually the performance of your websites. So if you are building tons of crazy options and flexibility onto the page loading, then that can hinder the amount of time that it takes for that page to load. And so there’s lots of considerations. Something else just to think about is who will be maintaining and updating the CMS in the future. That may seem obvious to think about, but if you’re planning on taking over support for your CMS after a web project or you’re thinking of doing this internally, you need to make sure that the people who are going to be updating the CMS are onboard with the technology you’re choosing.

And now, it’s time for another poll. Rachel, you want to do that?

 

Rachel: I’m on it, Stephen.

Stephen: Okay.

 

Rachel: Here we go. Question, how many third-party systems feed into your current website? And here’s what we mean about that. Think about your email marketing system, your CRM, or customer relationship management system. Maybe you’re an association. You have an association management system, or you do events, and so you have your registration system. It’s usually a lot. Let me end the poll and I will share results. Actually, they’re still coming in, so I’ll let you guys think about it. When I think about our website, I mean, it’s six plus easy, without a doubt.

Okay, I’m going to share this here. So most people are saying one to three, and then three to six, and then, I don’t know. And that’s why we ask this question upfront. It’s really important to think about all the things that need to plug into your new site and how those things are able to do that. So sometimes, your CMS requirements— correct me if I’m wrong, Stephen, but we’re looking at all the technology that needs to plug into it and what are the capabilities around that CMS for accepting those kinds of plugins.

 

Stephen: Correct, yeah. Or custom— it may not just be plugins, custom things we need to build integrations with.

 

Rachel: Yeah.

 

Stephen: So, that’s why question number four is really big. What third-party systems do we need to integrate with? This is something that we think about at the beginning of every project. So your website is hardly ever an island like this, especially with the complex organizations that exist with a lot of our clients; government agencies, associations, universities, non-profits. There are almost always third-party systems that need to be taken into account, at least there have been on every project I’ve worked on that I can remember at least in the past 10-plus years.

 

So, what tools does your website need to interact with? The first step in this question is to just build a list of every third-party system or tool the website will need to interact with. And you don’t want to worry about the method or the details of that integration yet. You just want to make a list of every system. And you’re oftentimes going to have to think— work with your entire organization to figure this out. Look at your existing website. Have your IT team look at your website or your web developers. Have them think about how your organization handles lead forms and maybe tracking code, social feeds, newsletter sign-ups, events, payments. All that kind of stuff can play into this.

 

So, the second step is to figure out the method of integration for each of those. So for everything you made a list on, you want to think about, does this integration need to be simple or complex? What I mean by that is maybe on the simple side is just a piece of embed code. Like, YouTube is a great example. YouTube may be integrated with your website, but it’s just a piece of embed code you grab from YouTube and you plop into a field line on a page on your site. Or is it just a link off to a third-party site? Sometimes, an integration may seem really complex at first, but all that is really needed is a link off to a third-party website, so don’t make it more complicated than it needs to be. The second kind of level-up, is it a one-way data feed, which means does a website need to ingest data from a third-party and ingest—I mean, consume somehow? Does it need to take that data and do something else with it, or does your website need to send data over to a third-party?

 

And the next level-up, is it maybe a full API integration that requires a more complex custom code? So to help figure out the method of integration, you can start asking yourself, or your IT team, or whoever is involved, do you need to share data back and forth between these two systems? So, for example, imagine events that may live in an event management system. Let’s say you have your own event management system, and at first, you may think all you need to do is link off to that system so people can register for events. However, then you realize that you want to display those events on your homepage. So the event management system might have some embed code you could use to embed a kind of widget, but it may not look cohesive with your site. You may not like that option. And so you realize you actually need that content in your content management system, so then your content administrators can easily choose which events show up on your homepage and that’s all integrated and looks nice. So an option may be to import the details of those events from the event management system into the CMS so we can display them where they’re needed across the website, and then just link over from the website to the event management system for the registration and payment. That’s something common we do all the time. And so that’s kind of an example of how we need to pull data into the content management system, but we don’t need to share data with the third-party system in any way.

Something else to consider here is, will your website and a third-party system both need to know someone has logged in successfully? And we’ll talk a little bit more about single sign-on in a minute, but that’s a big question too.

 

Rachel: Stephen, can you talk a little bit about API? Just give a little bit more information about what that is from a layman’s perspective.

 

Stephen: Yeah. So API just stands for application programming interface. And at its core, a very simple definition is it’s just a language that computers can use to talk to each other. And so most third-party systems have a documented API, and that means you can look at this documentation and figure out how the data is structured that you can pull in or how you need to send them data and that type of thing. So it’s just kind of instructions for how two computers talk.

 

Rachel: Great, thank you.

 

Stephen: Sure. So question number five is, will a third-party website need to be skinned? So third-party websites can often be customized with design elements, you know, logos, colors, that type of things, to match your brand. And we call this process skinning. So when your visitors’ login to a third-party system that is linked from your website, you don’t want it to look completely disconnected. So you want to make sure that the third-party system ideally has elements of your brand, of your new website for a cohesive user experience.

 

So, for example, this is an example of a website we created for the American Association of Nurse Practitioners. And then this is just a simple example. This is their membership login. And we’re working, actually, on an updated version of this, but just for this example, you can see at least they’ve identified their logo, their colors, their rounded buttons, the similar fonts from the main website. So it’s not completely jarring when you click and go off to this login screen. It looks cohesive.

 

So, you want to ask first, which third-party sites should be skinned? And so basically, if a third-party system has a website that people are going to interact with, it should be skinned. And then you want to find out which of those third-party sites can be skinned. So you’ll have to work with your third-party system to find out do they have any capabilities to adjust the design of that site. And then after that, you want to find out what are the limits for each of those sites. So what extent can you skin the third-party site? Can you only change colors, or can you also adapt fonts and imagery and that type of thing?

 

Rachel: As a former designer and a purist, I will say that I’m often disappointed by how much you can actually skin a third-party platform. So, like you just do the best you can; fonts, colors, make sure your logo’s there. What you don’t want to do is create something where say you have a login for membership, and someone’s on your site and they hit that login button and then they end up on this thing that looks nothing like your current site. That causes confusion, and we never want our users to be confused.

 

Stephen: Yes, great point. So another thing we want to consider is the responsibility or timing. Who is responsible for skinning each system? Is this something you have to do, or is it something the third-party provider is going to take care of for you? And the timing, how long does it take, and is this going to maybe delay the main website project? Because a third-party might require a set of front-end files from your web development team, like the styles and that type of thing, in order to create the same look and feel on their system. But if you provide those too early in the process, then things might change on your side, and they may have to redo some of their work. Or if you provide it too late in the process, then you might end up needing to wait for the third-party to complete their work before you want to launch your new website.

 

Question number six, will we need a single sign-on? So single sign-on is a configuration that allows your users to use one set of credentials, a username, and password, to log on to multiple related systems. So if your organization has different systems for, for example, your main website, event registration, calendar, that type of thing, you don’t want to require your users to log in to all three of those different usernames and passwords because that can create strain and security risk. So instead, you want to offer them a single sign-on for all the integrated systems. So the first question is, do you really need it? Does your new website need to know that visitors to your website have already signed in to a different application? This is something we see often with association management systems or other things like that. These need to be connected in some way so people feel like they are in one cohesive experience.

 

Rachel: Can I give an example here, Stephen?

 

Stephen: Huh?

 

Rachel: Can I give an example here?

 

Stephen: Yes.

 

Rachel: I’m thinking of— again, I’ll do an association only example where you have member-only content. So if I’m on the website and I’m not logged in, I don’t get to see that content because it’s members only. But if I log in to the back-end, and that is tied into the association management software, so it says, yes, this is a registered user, now the website needs to show me that content. And so in that way, I have a single sign-on for both the website and the membership site that those two things are talking to each other and they need to have a single sign-on.

 

Stephen: Yeah, exactly. That’s a perfect example. This can also include letting people log in to your content management system back-end using accounts external to the content management system itself, so something you want to consider. And just like Rachel said, a big reason for this is gated content. So that’s content that is only available to your members. Then you have to build a single sign-on.

 

If you’ve determined you do need single sign-on, then the next question is to ask whether your website needs to know information about the logged-in user or does it just need to know that they’ve signed in. Does it actually need to know, like, their membership level and their join date or whatever this is? Like, does it need to know some information, their name, their email address, or does it just like—yes, this person’s signed in or they’re not. Because that can determine the complexity of this integration. So if you do determine you need single sign-on, then you need to start thinking about the technology. Who is going to serve as the identity provider? And what that means is the system that kind of holds the master record for each user account is the identity provider. If you already have a separate membership system or if you use something like Azure ID or something like that already in your organization, then that’s going to make the decision for you. That’s the identity provider. But if not, you may have some other options to consider. And you may not know the answer to this question, but you need to find out the technologies your system can support, or the person who’s going to be building this needs to find that out. There’s some common single sign-on technologies that we use like SAML or LDAP. You don’t have to know what those mean, that’s fine. But just the technical discussion is going to need to happen in order to figure out if there’s easy ways for the two systems to talk to each other.

 

Question number seven, how will we handle site search? So do people need to search through content on your website? And the answer is most likely yes. Sometimes maybe not if it’s a very small site, but for any site that has a lot of content, yes. So building a search engine for your site can be a pretty complex endeavor and you need to think about some of the requirements for that search engine before you decide what solution you want to use for that search engine.

 

So the first thing to ask is, where does the data live that needs to populate the site search engine? And what I mean by site search engine is, usually on a website up at the top, there’s a search bar, and that’s just searching through content on the website. Is this data coming from multiple systems? So are those systems— does it need to come from an internal-only database that houses some records that you want people to be able to search through? Or do you need to index content on a third-party website? One of those websites we talked about, may need to be skinned. So you need to figure out the requirements around where is the data that this search engine is going to need to access. Do you need to have the text of files, such as PDF files, indexed by your site search engine? That can kind of be a determining factor for what solution you use. Is any of the content that needs to be indexed only available to logged-in users. And if so, how sensitive is that data, and how secure is the search solution that you’re planning to implement? You don’t want to have members-only secure information indexed at a search engine that’s public. Does the data need to be categorized to offer filtered searches? So when you search for a term, then it gives you the option to narrow it down by filters, like you get on Amazon or any other number of websites now. If so, is that going to require some custom coding on your side to add information to each page that’s going to feed that search engine, or is the search engine going to handle it all natively and not require any extra work from you?

 

Next, you want to think about some of the requirements for how you want to manage that search data. Do non-technical users need to modify the properties of the search engine? So, what I mean by that is would non-technical users maybe want to adjust some of the filtering rules around the categories that are going to show up? Would they want to customize results for certain keywords? So if someone types in this keyword that you know you have an excellent page about, do you want to force that to be up at the top? There are some great third-party solutions out there that would give technical users a lot of control over how the search results appear and how the pages are indexed, so you may want to consider those. But do you have a budget for those solutions? These can offer fantastic capabilities for cheaper than it would cost to have a web developer build a custom search solution, but it does cost money. And you want to consider the timing. So if a search engine needs to scan the public website, then you have to make sure that it’s all aligned along the launch date. Ideally, you have a way to feed that search engine prior to your set launch date.

 

Question number eight— this is the last one— what standards are we or are you required to follow, either legally or just best practice standards? These are just some possibilities. I’m going to throw these out here. And again, you’ll have access to these later so you don’t need to write all of these down. But what browsers does your website need to be compatible with? You need to look at some historical data, maybe from Google Analytics, to help make this decision about what browsers your users are using. Are there any specific security requirements or policies in place in your organization? For example, do you just need to adhere to security best practices or is there a defined list of security standards that’s written down that you need to adhere to? Are you going to have to allow time in your launch process for a security and penetration test? You know, actually trying to hit the website and hack into it. What privacy laws do you need to follow? This is a big one these days. Things like HIPAA, which applies to health insurance medical records, GDPR, the General Data Protection Regulation, or maybe even CCPA, which is the California Consumer Privacy Act, which is a little newer but kind of similar to GDPR. Are there performance requirements or expectations, either written or unwritten? For example, does someone of influence in your organization maybe believe that the new website is going to be a complete failure if every page doesn’t load in less than one second. If that’s an expectation, you need to find that out now.

 

Accessibility. So accessibility’s huge and you should be thinking about this from the very beginning of a new web project. Accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. And again, it needs to be brought in at the very beginning. Again, you don’t need to know what this means but you need to think about the level of accessibility you need to target. A common one is WCAG AA. And you can look more into what that means later. But that is the minimum, at least for every government project and typically for any project. You also cannot say that you are WCAG AA compatible with an automated scan alone. Automated scans are only going to catch about 40% of the issues, and so you need to have a plan for testing, which is going to include manual testing.

 

Rachel: I’ll just remind all the communicators here that you have tech people for a reason. And if you’re kind of like, ah, that’s okay. We know you’re going to have to talk to some tech people, right?

 

Stephen: Yeah, for sure. So just to sum it up, that was a lot of information, but kind of the summary is that building a website can be done in a million different ways. And there’s a lot of questions that you would want to ask upfront that’s going to help make that entire website process more efficient. And the goal of all these questions that we’ve talked about here is really just to create a list of technical requirements that can help guide you throughout the website project. So we have the slides and a download available at mightycitizen.com/8questions. There’s also some bonus tools and templates there. And we’ll leave this up for a little bit while we get to some questions so you guys can write that down or visit that site.

 

Rachel: I’m going to add too that we do have a—Jarrett mentioned this at the top, but we have a website technology planner that has all these questions in it. So if you’re just in the beginning— it comes before the RP, or the request proposal process—get that technology planner from that link and you’ve got all the questions right there for you. You can sit down with your tech team and answer them.

 

Jarrett: Stephen, we did have some requests for some of your Elvis, but I won’t scare you. We’ll go ahead and wrap up.

 

Stephen: Thank you.

 

Jarrett: Everyone, thank you so much for attending. Please remember that we’ll be sending out the slides and the recording of this webinar to everyone who registered regardless if they attended or not. So you’ll be receiving that in your inbox shortly. We’ll also include a link to a feedback form, a survey for our webinar today, and we hope you’ll take a minute just to tell us what you think about our job today. If you want to get started immediately, you can download our website technology planner at mightycitizen.com/8questions. I also just put that in the chat. Or we’ll be sending that via email in the next few days as well. If you have any questions at all about what we talked about today, please feel free to email us at hello@mightycitizen.com. Stephen, Rachel, thank you so much again. Everyone, thank you for joining us. Have a great rest of your day.

 

Rachel: Thanks.

 

Stephen: Thank you all.