A blog by the Brick Factory The Brick Factory
torture

Preventative maintenance: the key to keeping your website healthy and safe

Life is full of things we do because we have to. Trips to the DMV.  Jury duty.  Paying taxes. Dental appointments.  Oil changes.  These things are no fun.  But as painful and tedious as these tasks are, the consequences of not doing them are far worse.  

Spending $50 and an hour of your life getting an oil change sucks.  Having your car break down and paying thousands for repairs sucks worse.

In the web development world, updating your site’s software and server operating system are the equivalent of getting an oil change.  It is preventative maintenance done to mitigate the risk of future failure.  And given the lack of an immediate, tangible benefit, it is something that many are tempted to skip.  

Most of the sites we maintain are run in LAMP/LEMP (Linux Apache/Nginx MySQL/MariaDB PHP) environments and powered by Drupal or WordPress.  We typically recommend clients perform preventative maintenance on their sites once a quarter, speeding up the timeline when critical security updates are released.  There are a number of reasons why keeping to a regular, preventative maintenance schedule is important:

  • Security.  Platforms like WordPress and Drupal are extremely popular and widely used.  Given their ubiquity, malicious users are constantly working to hack or hijack sites powered by these platforms for personal gain.  If you don’t perform security updates regularly your site runs a high risk of having major security holes that hackers can exploit..  
  • Bug fixes.  No platform as large and complex as Drupal and WordPress is 100% bug free.  If you have worked in either platform there is a good chance you have stumbled on a small bug that impacts your work.  By performing regular updates you get access to bug fixes made by the community.  
  • Access to new features.  Hundreds of developers are constantly improving Drupal and WordPress  through the release of new features.  You can only get access to these new features if you update to the latest software version.  You have access to the latest and greatest version of the platform.  
  • Preventing obsolescence.  If you keep up with updates, the time investment is pretty low.  On most sites a few hours a month are all that are needed to maintain a site.  If you put things off for years, the problems pile up.  The updates become difficult or even impossible in some cases.  A neglected site can get so behind on updates that it is obsolete.

While we try to communicate the need for preventative maintenance to our clients, we’ve been involved with a number of projects where it wasn’t a priority.   In some cases the client has skipped updates for long periods without any negative consequences.   But we’ve seen other cases where clients have suffered disastrous losses as a result of neglecting updates.

Recently we had a client with a site built in WordPress who hosted and maintained their site themselves.  They got behind on updates on one of their core sites and a hacker got access to their administrative tools as a result.  Likely in effort to improve SEO on a site they were affiliated with, the hacker quietly inserted links to third-party sites on highly trafficked pages and created a bunch of new, spam pages.  The hacker exploited the site for months before they were detected.  As a result of the attack the client’s SEO rankings for the keywords they are taking took a big hit and they spent tons of time trying to expel the hacker and manually cleaning up content.

We came across another example recently when talking to a prospective client.  The organization was years behind on Drupal updates and were targeted by a malicious hacker.  The hacker defaced their website, deleting content and hijacking their homepage.  In addition to not updating the site, the client also wasn’t performing regular backups.  As a result they had to rebuild their entire site from scratch and rewrite a great deal of content.  It was a disaster.

Businesses and organizations spend untold time and money building and maintaining web presences.  Given the investment and importance of web programs to most organizations,it is dangerous and short sighted to not invest in preventative maintenance.  

members_blog

How to create a members only section that people will actually use

If you work at a membership-based organization such as a professional society, trade association or nonprofit, the situation below may sound familiar:

Your members have periodically asked you to provide them with ways to collaborate with each other.  You decide to act on the request and build a new members only section on your website with frequently requested features such as a member directory, member profiles, message boards, group chat and document library.  You launch the new section and get good initial feedback.  But after a few weeks it becomes clear that no one is using the new tools and after a few few months it is a complete ghost town.

You bought the groceries and cooked the meal, but no one is coming for dinner.

In my experience, this is the rule rather than the exception.  The features that sound the most exciting in theory are often quite different from the ones members will actually use on a daily basis.  Perhaps more importantly, your member’s only section is competing for attention against the likes of Facebook, Slack, LinkedIn and Pokemon Go.  Getting people to make your site a part of their daily or weekly routine is a tough ask.  

To help prevent you from wasting blood, sweat and tears building something no one will use, below are some lessons I’ve learned building members only sections for clients.  

(1) Listen to your members

A lot of expensive and unneeded features that get included in members only sections are the result of anecdotal requests (“Board Member A thinks Feature X would be really cool”) and/or poorly constructed membership surveys.  Asking members what features they want is a vital part of the planning process, but you have to ask the right way.  You need the right mix of quantitative and qualitative research.

Don’t just send an open ended email survey asking members what features they would like to see.  Instead, develop a list of features you are thinking of adding and ask members to rank them in order of importance and/or to tell you how often they would use each of them.  You need to a way to prioritize features into “must” and “nice to” haves.  

Be sure to send the survey to all your members, and not just a small subsection.  The needs of your most involved members are going to be different from those who are less active.  Don’t let the loudest voices drive your development priorities.

Lastly, supplement the email survey data with qualitative research.  Interview a few members over the phone or in person to get a sense of how they are using your current members only section (if you have one) and/or how they would use the new features you are contemplating.  Interview members from a variety of backgrounds and engagement levels.  These interviews can be really helpful in understanding how members actually use your site and fine tuning requirements.

(2) Don’t recreate Facebook and LinkedIn

I have worked with a lot of clients who want to build advanced social networking functionality into their members-only site.  They basically want to create a “private” LinkedIn or Facebook for their organization, with groups, status updates, chat, message boards, etc.  

In my experience this approach is nearly always a mistake.  These types of social features sound cutting edge and exciting, but are rarely used in the context of a members only section.  Most of your members aren’t going to spend enough time on your site to support features like chat or message boards.  

If you do want to experiment with social features, a better approach is to try to leverage social networks your members are already using.  Start a private group on LinkedIn or Facebook.  Experiment with Slack.  Start an email discussion list.  These tools are more cost effective and likely to success than trying to build your own walled garden on your site.

Fish where fish are.

(3) Start small and expand

In software development, “the minimum viable product (MVP) is a product with just enough features to gather validated learning about the product and its continued development.”  In the context of a members only section, the MVP should consist only of the “must have” features you and your members have identified.  Start out by building just these features and then expand later based on your site analytics and member feedback.  This approach allows you to move quickly, and saves you time and money that might have been spent building features people won’t actually use.

As an example, we recently built out a members-only section for a professional society.  They started out with a long list of feature requests that included expensive social features.  After research and a series of discussions, their MVP consisted of the following features:

  • User accounts for members with different permissions based on membership level.
  • Members-only document library
  • Listing of members-only events and continued learning opportunities
  • Access to proprietary database showing overall industry trends
  • A really good search of all the members-only materials.

The professional society had a wealth of proprietary content that their members rely on in their day-to-day work.  Providing their members with a way to quickly and easily access this content was far and away the most important feature for the new members only section.  So for phase one of the project, we focused on doing that one thing really, really well.  We focused on the area where the professional society could provide its members with real value.  

project management pitfalls

How to avoid three common project management pitfalls

A few weeks ago I wrote a post about how important it is for project and account managers at web development firms to have empathy.  If you are able to see the world as your client does, chances are you are going to do a great job for them.  You will be able to anticipate problems before they happen.

As a follow up, I wanted to share some real-world examples of client communication problems we’ve run into at the Brick Factory and explain how they could have been prevented.  The underlying theme is that most issues can be prevented with good communication that comes from understanding.  

(1) Hidden Requirements

Project management problem

You have been working on a site redesign project for three months and are a week from launch.  While reviewing the beta version of the site, the client points out that a members-only section that was present on their old site is missing and must be built prior to launch.  This is the first you have heard of this feature.  Your launch date is now in peril and you have to have a difficult conversation with the client since the work isn’t in your original Scope of Work.

How it could have been prevented

No matter what project management methodology you use (Agile, Waterfall, etc.) or how small a project is, every engagement should begin with a discovery phase aimed at surfacing requirements.  Write out the features and functionality of the site/feature you are building and get the client to review and approve to make sure nothing is missing.  

Skipping the discovery phase is sort of like heading out on a cross country, family road trip without a map or GPS.  You will probably get there eventually, but it is going to take a long time and there will probably be tears.

(2) Misinterpreted Designs

Project management problem

Your team has produced a series of design comps for a new site that you are ready to show the client for the first time.  Language and photography are still being finalized, so you use placeholders in the initial comp.  You send the client the designs via email and don’t hear back for a week.   When they finally do get back to you most of the feedback is on the placeholder images and text, and it becomes clear that the client is confused by parts of the interface.   You are able to clear up the confusion with a phone call, but you have wasted a week.

How it could have been prevented

This one is pretty simple: you should always present your first big design deliverable either in person or via a screen sharing service where you can control the experience.  You should only send a link to the design after you have presented the work first.

By presenting the work you are able to explain the decisions you made, fully demo how the interface works and clearly define what kind of feedback you are looking for.  It gives you the opportunity to make sure your work is properly understood.  No matter how thorough or well written an explanatory email, it can’t take the place of a conversation.

(3) Misunderstood Deliverables

Project management problem

You create a series of wireframes for a new website you are building.  The wireframes are in black and white, and intended to demonstrate overall page structure and content priorities.  After sending the wires to the client, you get a short response asking why the new site design is completely black and white.

Later on in the project, you send the client a complete, full color design comp that is in PSD format and optimized for widescreen desktop computers.  The comp is posted in Invision so that the client can see what it will look like in a browser and provide feedback before you build it out in HTML/CSS/JS.  The client calls you five minutes after receiving the comp in a panic, asking why the new site draft doesn’t work on mobile phones.

How it could have been prevented

In both of these scenarios the client misunderstood the deliverable you sent.  In the first scenario they thought the wireframe was a full site design and in the second scenario they thought the design comp was a full working site draft.  

If you are like us, your clients are smart people who are true experts at their jobs. But for a lot of them web development isn’t their primary job.  They count on us to walk them through the process of building a site.  It is a mistake for us to assume that all of our clients know what things like wireframes, design comps, mood boards, prototypes, etc. are.  

One of the first things a project manager should do when onboarding a new client is explain the process that will be used to build the new site or feature.  Walk them through each of the deliverables you are going to produce in detail, explaining what they are for, what their limitations are and what type of feedback you are looking for.  I know this sounds obvious, but I personally have skipped this step and ended up confusing the client more times than I care to admit.

empathy_blog_art

Empathy: a project manager’s secret weapon

Our Brick Factory team recently moved into a new office in the McPherson Square area of Washington, DC.   Our new space was previously occupied by a law firm with an affinity for wood paneling, ship drawings and 80s style carpet.  Thankfully, as part of our lease we were given the opportunity to completely gut the space and rebuild to our exact specification.  This involved a pretty extensive construction project with deadlines, budgets and a team of contractors.  As the client on the project, my job was to oversee the process and to make a million small and large decisions.

I had never been involved in a construction project before and it was quite a trip.  I pretty much felt confused and incompetent the entire time.  I didn’t know speak the language or truly understand the process. I asked many, many stupid questions and had to have things explained to me 2-3 times before I was able to “get it”.  I lived in fear that I would make an expensive mistake.  Despite my extremely shaky performance, the new office turned out great due to the wonderful job done by the team we worked with.

Managing the construction of our new office increased my appreciation for our clients.  Being the client is hard.  By playing the role, I was able to gain a greater understanding of the stress and emotions our clients feel when working with us on web development projects.

At the Brick Factory our clients are smart, busy people who spend their days fighting important policy battles, running successful businesses and/or trying to make the world a better place.  Their jobs are hard and stressful, with deadlines and goals they rely on us to help them meet.   While the web is critical to what they do, building websites is rarely their primary job and not all of them have a deep understanding of the web development process.  

In order to do right by your client, I think one of the most important traits you can have is empathy.  There is a lot of good content on the web about empathy (go watch this video right now), but this definition sums it up pretty well:

The ability to step into the shoes of another person, aiming to understand their feelings and perspectives, and to use that understanding to guide our actions. 

If you think about it, that is a pretty good description of what a project manager does.  If you are able to see the world as your client does, chances are you are going to do a great job for them.  You will have a deep understanding of their needs, and will be able to prevent most problems and resolve the ones that do pop up quickly and amicably.   

While certainly incomplete, to be an empathetic project manager you have to do the following:

  • Understand your client’s background and experience level.  The way you work with a client that is managing their first web development project is going to be fundamentally different from a client with a wealth of experience.  Understand your client’s experience level and adjust your process accordingly.
  • Know how your client likes to work.  Some clients want to be involved in every decision while others want to provide overall direction and let you handle the details. Sometimes it is a mistake to ask for feedback too often. Other times it is a mistake to not ask often enough.  If you understand your client you’ll know what to do.
  • Get to know your client’s company culture.  Is the organization fast paced or laid back?  Who does your client contact report to?  Does your client email you late or night or just during the business day?  Understanding the environment your client is working in will help you provide them with better service.
  • Understand what is keeping your client awake at night.  Is there a big conference they are preparing for?  A vote on a big bill that is fast approaching?  A fundraising number they need to hit?  If you truly understand the client’s pain points you’ll be able to provide better counsel.   
  • Always figure out the “why” behind a request.  As a project manager you have undoubtedly received an out-of-the blue request to move a deadline or to implement a new feature ASAP.  Take the time to understand the context.  This will allow you to distill the request down to its core, providing  you the information you need  to solve the problem.  
  • Actually talk to your client now and then.  A lot of work today is done via emails and collaboration tools such as Basecamp.  Make the time to talk to your client on the phone and/or in person now and then.  You will undoubtedly learn something you wouldn’t have known if you’d stuck exclusively to electronic communication.  This will build connection and understanding.

When you are a project manager at a web development firm, it is very easy to turn into a robot programmed to complete tasks as quickly and efficiently as possible.  But being able to put yourself in the client’s shoes is just as important as efficiency.   Indeed, empathy is often the difference between a great project manager and one that is merely good.

How We Built It: International Youth Foundation Annual Report

A few weeks ago I wrote a post about changes we have made to our Brick Factory design process over the last few years.  Check out the full piece if you have time, but the gist is that we haved moved away from designing pages and towards creating systems.  We are trying to design overall styles and repeating elements that make up the pages, instead of the pages themselves.

Showing is always better than telling, so I wanted to write a follow up post using the Annual Report micro-site we built for the International Youth Foundation as an example.  What follows is an explanation of our design and build process for the project, with actual deliverables included to make things more concrete. (more…)