A blog by the Brick Factory The Brick Factory

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: 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…)

design system

Design Systems, Not Pages

For most of the web’s short lifetime, the primary way to design a website has been to create  wireframes and comps (design compositions) of a site’s key pages.  Oversimplifying a bit, designers  identify these key pages and essentially create pictures of what the pages  look like when presented on the web.   The designs are typically done with desktop computers in mind and at a fixed screen width.

The client or product owner provides feedback on the work and eventually approves the page designs.  The comps then get converted into HTML/CSS and built out as templates in whatever Content Management System is being used. And done! Like magic!

While not exactly easy, this process more or less worked for a long time and was the primary method most firms used to design websites.  For a variety of reasons, over the last few years this page-centric design approach has proven to be irrevocably broken.  The page-based approach is simultaneously time consuming and ineffective at showing what the end product will actually look like.

Following we explain the problems with page-based design and how our Brick Factory team has transitioned to a system-based design approach.

Why page-based design doesn’t work

Rise of Smartphones and tablets.  

Five years ago, nearly all website traffic came from desktop and laptop computers.  If 10% of a site’s traffic came from phones and tablets that was a lot.  Today it isn’t unusual for a site to see 50% of traffic coming from phones and tablets.

And within each of the main device categories (phones, tablets, desktops and laptops) there is a ton of variance in screen sizes.  For our average site, the  most popular screen size (usually 1366 * 768) is used by only 10% of visitors.  For the highly trafficked websites we work on, we might see as many as 1,500 unique screen resolutions each month.  A single site design must  provide a good experience on gigantic desktop monitors (2560 * 1600) and tiny mobile screens (230 * 270).  As you can see, these are two very different balls of wax.



Given the range of screen resolutions, creating designs comps of a bunch of pages at arbitrary screen sizes just doesn’t make a lot of sense.

Increased Complexity of Interfaces

Web design has gotten a lot more sophisticated over the last few years.  The projects we complete for our larger clients feel more like applications than simple websites, with user inputs often driving how the site looks and behaves.  Designing these interactions out as “pages” requires a ton of page comps.  For example, a donation system for a nonprofit client could easily require 10-20 page comps by itself.

Even simple websites are much more complex than they were four or five years ago.  A four or five page promotional website today is likely to include sophisticated transitions and animations that are difficult to convey in a page comp.

It just isn’t efficient to demonstrate this sort of complexity via flat, page-based design comps.

Page-Based Design Doesn’t Scale

Due to the proliferation of screen resolutions and increase in complexity, on large projects we have ended up doing a staggering number of wireframes and design comps when using a page-based design approach.  Whereas four or five years ago a complex project might have meant twenty page designs, today it can easily mean 50-100.

The sheer volume of comps that we have ended up producing has lead to consistency problems.  If every page is designed separately, unnecessary and redundant design elements are very likely to get introduced.  This makes the resulting site harder to build and maintain, and the overall quality of the work is compromised.

Page-based design just doesn’t scale.

Bottom Line

Perhaps the biggest problem with page-based design is that it creates an inaccurate representation of how the end user will experience the resulting website.  The designs a client approves don’t really reflect what the site ends up looking like.

Once those pixel perfect PSDs are turned into HTML/CSS and viewed in different browsers at different screen resolutions, they often look pretty different.  All that painstaking design work is sort of wasted, as you still end up spending a ton of time polishing the site once you have a working draft.

Ultimately with page-based design there is a fundamental disconnect between the way the site is designed (flat PSDs) and the way it is built (HTML, CSS, Javascript, etc.).

So What’s the Solution?

While it has been a bit of a struggle, over the last few years we have made a conscious effort to move away from page-based design.  Along with many other designers, we are trying to design systems instead of pages.

While we are still refining our approach, for us this means creating a design process that is in tune with the way websites are actually built and function.  We design overall styles and repeating elements that make up the pages, instead of the pages themselves.  So instead of fifty design comps, for a project today we might produce the following design deliverables instead:

  • An overall style guide that defines palette and typography and the look/feel for critical, repeated site elements such as buttons, bullets, forms, images and icons.
  • Designs for key components that will be used repeatedly on the website.  For our clients, typical repeating components might include a site navigation system, page header, email sign-up, photo gallery, news headline grid and donation system.  For components that require interactivity, we will produce  HTML prototypes in addition to or instead of a set a of flat design comps.
  • Content hierarchy and/or wireframes that define what components make up each of the page templates we create.
  • Wireframes and design comps for a few important pages so the product owner or client can get a sense of what the end product will look like.  We aim to limit this to a handful of key pages instead of creating a design for every unique page and template.

After we get these key building blocks designed and approved, we start creating the site templates in HTML/CSS and see what things look like.  We then allow ourselves plenty of time for refinement and polish.  Instead of front loading all the design work, we take a more agile approach and fine tune the design after we see what the working draft looks like.

We haven’t perfected our process yet and by the time we do everything is likely to change again.  But, at least to us, this system-based approach makes a lot more sense than producing an endless series of page comps.

We wrote a follow up to this post walking through a project that uses a systems-based approach.