A blog by the Brick Factory The Brick Factory
moving

Lessons in Requirements Gathering from our Search for a New Office

Since we launched the company three years ago we’ve made our home at an office building on 17th and M in downtown Washington, DC.  It is a nice space and the location is fantastic.  We are in the Golden Triangle area, which is walking distance from a variety of great DC sites and neighborhoods (Dupont Circle, Logan Circle, the Mall, etc.), near the Metro and close to more restaurants, food trucks and bars than we have time to try.  We have been happy here.

We found out a few months ago that our landlord will be tearing down our office building, along with 3-4 others, to build a new mega building that will be geared towards high-end corporate tenants as opposed to small businesses like ours.  We have to be out of our space by the end of the year, so with mixed feelings we began our search for a new office a few months ago.  We’re excited by the opportunity to craft a new space from scratch but apprehensive about all the work involved in moving offices.

As someone who has done project management in some form my entire career, when starting the search my natural instinct was to start gathering requirements in the same way I would when planning a new web program for a client.  As the owner of the company I had a pretty clear idea of what I wanted in our new space, but I needed to hear from the rest of our staff about what they were looking for.  I needed to conduct a discovery process.

As a first step, I put together a short survey that asked staff what was most and least important to them in the new office.  We have a distributed team, with half of our twenty person staff working out of the DC office and the other half working remotely and coming into the office a few times a year.  So it was important to construct the survey in a way that differentiated the needs of these two types of users.

The results mostly confirmed my assumptions.  We are a Washington, DC firm and our office needs to be in the city.  Metro and bus accessibility are critical, as is access to plenty of restaurants and bars.  But the survey revealed a few things that were surprises to me:

  1. Our current space has windows on only one side. And those windows are only able to be enjoyed by three people who have offices that overlook M Street. The survey revealed that the rest of the staff are starved for natural light.  Katie even went so far as to forward me articles about how a lack of natural light negatively impacts sleep patterns.  As one of the few people with an office with a window, I had taken it for granted and undervalued how important light is to those that don’t have it.
  2. Nobody really cared that much about building amenities.  Perks like a concierge and fitness center just aren’t that important to our staff. People don’t want or need a lot of bells and whistles.  These things were more important to me than the rest of the team.

Based on these survey results and my conversations with staff, I put together a requirements list. Since we need to work within a budget, it was important to prioritize our needs in the same way I would ask one of our clients.  I separated our requirements into lists of “must haves”, “nice to haves” and “don’t needs” that were put into priority order.  These requirements  were very similar to the lists of user stories we create when planning a web program for our clients.  Here is what the list  looks like:

Must Haves

  1. Office is in Washington, DC.  We do not want to move to Virginia or Maryland.
  2. Office is Metro and bus line accessible.
  3. Office has space for four private offices.
  4. Office has space for eight other work stations.  An open space plan is preferred over cubes.
  5. Office has a main conference room capable of seating at least eight people comfortably.
  6. Office has a kitchen with refrigerator, sink, microwave and dishwasher.
  7. Office has small storage room and server closet with room for a server rack.
  8. Office has space for 3-4 large filing cabinets.
  9. Office must have access to extremely reliable Internet Service Provider.

Nice to Haves

  1. Office has more natural light/windows than current office.
  2. Office is in same part of town as current office.
  3. Office has extra space/workstations for telecommuters when they visit.
  4. Office has a small secondary conference room optimized for four people.  Primarily used for small team meetings and conference calls.
  5. Office has main conference room capable of seating 16 people.
  6. Office has area where people can eat lunch together.
  7. Office has gym/showers in building that employees can use.
  8. Office has in building parking garage.
  9. Office has concierge.

Things We Don’t Need

  1. Office has a formal reception area.  Our company has a flat structure with no admin staff, so we don’t need to waste space with a reception area.
  2. Office doesn’t need large work room. We have one in the current office and it has basically become a place for Ron to indulge his hoarding problem.

We sent our requirements list to our real estate team who are using it to narrow down our options and to construct our space plan.  We started touring offices last week.

In the context of web development the goal of a discovery process is to surface requirements and priorities early on to minimize surprises late in the process.  Work done up front saves time down the road.

While not nearly as involved as the process of planning a website, I think the simple discovery process we performed in planning our office will pay dividends down the road.  It will help us focus our search and provide a solid framework with which to make our final decision.

How the Rise of Smart Phones and Tablets Is Impacting Our Clients

With the proliferation of smart phones and tablets over the last few years, the hype about the mobile web has gotten pretty deafening.  While overall industry trends are important, at the Brick Factory we are more interested in understanding how the rise of the mobile web is impacting our own world of non-profits, advocacy groups and brands.

In an effort to truly understand how smart phone/tablet usage is impacting our clients, the last few years we have taken an aggregate look at visitor trends of the websites we manage (60+ sites).  Below are the key findings from our look at 2014 traffic data.

Overall Trend

Cutting to the chase, smart phone and tablet visits to the sites we manage grew aggressively in 2014.  Just under 32% of visitors came from smart phones and tablets in 2014.  Here is a graph showing the trend since we starting tracking this in 2010:

tbf_mobile_visitors_final

After more than doubling every year from 2010 to 2013, traffic from smart phones and tablets only increased by 70% from 2013 to 2014.  While I expect the percentage growth to slow further this year, I still project that by the end of 2015 close to 50% of the traffic to the sites we manage will come from smart phones and tablets.

Variance

While the aggregate trend is obviously important, diving into the data it is clear that each site has its own unique story to tell.  Traffic from mobile devices ranged from 2% to 70% among our client base.  Here is a graphic that demonstrates how much the mobile/tablet traffic percentage varied from site to site.

tbf_mobile_variance_spread-final

The audience and goals of a site/organization has a huge impact of how much traffic comes from smart phones and tablets.

As an example, one of our clients is a company that focuses on professional development for large corporations.  Since their clients are primarily accessing their web properties from work computers during office hours, their mobile/tablet percentage was only around 15%.  Due to the nature of their work, their target audience tended to access the site from desktops/laptops more often than our average client.

Contrast that with another client that is a large advocacy group.  This client maintains an active blog, sends out daily email alerts and frequently comments on breaking news.  50% of their traffic comes from mobile and tablets.

Smart Phones vs. Tablets

Smart phones were used to access the sites we manage more than twice as often as tablets.

tbf_mobile_piechart_final

Interestingly, we saw a moderate increase in overall traffic from desktops and laptops.  This increase was just dwarfed by the more dramatic increase in accesses from mobile phones and tablets.  For our clients at least, the story isn’t that desktop and laptop usage is dying, it is that visits from phones and tablets are exploding.

Android and Apple

Interestingly, more people accessed the sites we manage from Android smart phones than from iPhones in 2014.  The iPhone was the dominant device from 2010-2013.  The iPad continues to dominate the tablet market.

tbf_mobile_tablet_mobile

Bottom Line

The conclusion here is obvious: responsive design is now the rule and not the exception.

Back in 2010 and 2011, when planning projects we treated making a site mobile-friendly as a nice-to-have for most of our clients.  The percentage of visitors coming from smart phones and tablets often didn’t justify the added time and cost required to make a site mobile-friendly.  Creating a great mobile and tablet experience is now very clearly a requirement for every project we work on.

Five Great Campaign Websites from the 2014 Election Cycle

Having worked in digital politics in a previous life, I observe elections these days with mixed feelings from a safe distance.

Working for political campaigns is hard, stressful and often demoralizing.  The long hours rewarded with below market pay.  But the highs are pretty high.  When you are working on a political campaign it is your whole life for a time.  The small victories, like watching the money come in after sending a good fundraising email, are often nearly as sweet as winning the election.  It is both completely awful and exhilarating at the same time.

Knowing how hard campaign staffers and consultants worked during the 2014 election cycle, I wanted to acknowledge some of the great work digital teams did this cycle.  So, without further throat clearing, here are the five best campaign websites I came across this cycle.

(1) Ed Gillespie (R-VA)

Mark Warner edged out Ed Gillespie in the Virginia Senate race, but I think Gillespie had a slightly better website.  I like the use of photography and the site’s responsiveness is a step above the default behavior you’ll get from most HTML frameworks.

My only compliant about the homepage is the video, which feels like something that wasn’t planned for in the original design and got thrown in at some point.

ed1

The entire navigation system is nicely implemented.  I particularly like the Take Action bar on the left that encourages users to volunteer, donate, share or sign up for the email list.  It is unique and nicely implemented.

takeaction

Like just about every campaign this cycle, the Gillespie team  had a look at the Obama donate page.  The layout and functional of the Gillespie donate page is pretty much identical to the Obama version.

eddonate

 

(2) Mitch McConnell (R-KY)

The Mitch McConell site features a giant background video at the top of every page that references Lincoln, coal miners, Kentucky, soldiers, McConnell and AMERICA.  I’ve made an animated gif of part of the background video below, but you should visit the site to see the full piece.

mitch

While I’m not sure it belongs on every page, I appreciate the boldness of the approach.

(3) Alison Lundergan Grimes (D-KY)

While it lacks the trippy background video, the site of McConnell’s opponent Alison Lundergan Grimes is probably better overall.  Great use of photography and the whole site is just solid.

alison

I particularly like the collapsed state of the navigation bar and the way the Get Email Updates and Support the Campaign call to actions stay fixed on the screen as you scroll down the page.

alison-2

(4) Nathan Deal (R-GA)

The Deal campaign basically ran back their site design from 2010, going with bold photography and minimal text.  It still works.

deal

The site works just as well on mobile as it does on desktop.  I particularly like the the mobile version of their menu.

deal-mobile

(5) Chris Coons (D-DE)

The Coons campaign site features bold photography and a unique icon-based navigation system.

coons-home

As with the Gillespie campaign, Coons donation provider Act Blue had a look at the Obama donation page.

coons2

What were your favorite sites from the 2014 cycle?

Complete Brick Factory Card Set

This Summer we’ve been posting mock baseball cards of our employees on our Facebook page.  We’ve done this partly as a way to introduce our awesome staff to folks, and partly to amuse ourselves.  You can check out the complete set below.  Enjoy, and follow us on Facebook for more weird stuff like this.

blog_post_2

Off the Rails

How to keep your website review process from going off the rails

A few weeks ago I wrote a somewhat frivolous post that used 11 animated gifs to explain what it is like to build a website for a client.  I wanted to loop back and write a bit more substantively about the review phase of a project (represented in gif 9), which is the period between showing the client a functional draft of a site and its launch and completion.

In the post, I focus on how difficult it is to work through the final details that come during the review phase.  Correcting typos.  Switching out text and images.  Fixing small IE and mobile bugs.  Testing and debugging forms, ecommerce elements and CRM integrations.  This is all hard and tedious work that is mostly unavoidable.  You just have to grab some whiskey and power through.

However, a lot of the more painful aspects of the review phase can be avoided with good communication and planning.  Below are the most common mistakes I’ve made over my illustrious career, and some simple advice for how to avoid making them.

Hidden requirements

Hidden requirements are critical client needs that surface unexpectedly towards the middle or end of a project.  These hidden requirements are discovered most often during a project’s review phase, when the client first sees a working site draft.  The missing Salesforce integration the client finds when testing a form. The Member’s Only section the client forgot to tell you about.   Hidden requirements are one of the main reason projects go over budget and off schedule.

The best way to prevent hidden requirements from popping up is to have a discovery phase for every project.  During a discovery phase, everything should be put on the table.  The web development firm needs to ask good questions and the client needs to share anything and everything, no matter how small it may seem.  It seems obvious, but in order for a web development firm to efficiently build a website for a client they need a full understanding of the requirements of the project.   As Jordan Hirsch put it in his great Drupalcon session on requirements gathering: “You can’t ever truly skip a discovery phase.  You end up doing it even if the client doesn’t pay for it.”

Misunderstood deliverables

During the planning and design phases of a project, typical deliverables include user personas, site maps, wireframes, mood boards and eventually draft designs.  The goal of these deliverables is to help define a site’s structure and visual language prior to actually building the thing.  When used correctly, these tools dramatically increase efficiency.

A lot of our clients are communicators or policy folks who haven’t managed a ton of web development projects.  While the deliverables referenced above may seem self explanatory to me, they are frankly a little baffling to folks who don’t have a lot of web development experience.  As a result, sometimes clients end up approving deliverables without really understanding what they are approving.

As an example, for nearly all of our projects we produce a draft design composition in PSD form.  These comps show what a site page will look like when built.  When reviewing design comps, clients tend to focus narrowly on branding (photos, exact language, etc.) as opposed to structure (the elements of the page).  So we’ll often go back and forth with a client a ton on photography, and then find out about major structural problems only after we have a site draft done.  This is completely backwards.  Changing photos out once a site is built is easy.  It is much more difficult and disruptive to change structural elements after a site is in beta form.

When this sort of thing has happened on projects I’ve managed, it has pretty much always been my fault for not clearly explaining the purpose of the deliverables, and the ramifications and changes late in the process.  Clients need to understand what they are approving.

Poor review process on the client end

One of the first questions we ask new clients is what the review process looks like on their end.  Is the core team working on the project on a day-to-day basis empowered to make final approvals on all deliverables?  Or is there a Board or President or CEO that needs to review things in order for them to be truly approved?

If a review process requires approvals from people on the client side that aren’t involved on a day-to-day basis, it is vital that key deliverables are shared and approved throughout the site build process.  As an example, if a client requires CEO approval we might solicit their feedback and approval on our site plan, wireframes and the draft designs.

The key is to get feedback from all stakeholders early in a project’s life cycle, when changes are inexpensive.  What you don’t want is to build an entire site only to find out during the review phase that the CEO has a completely different vision for the project.  This has happened to me more than once.

Poor review process between client and web development firm

Back when I was younger and stupider, I was guilty of sending draft sites off to clients with vague direction asking them to tell us what they think.  The result was sometimes a free-for-all, with changes trickling in one-by-one over email from multiple people on the client side.  The changes often contradicted each other.

We now ask our chief client contact to compile feedback into a single batch of changes that are vetted and approved by all internal stakeholders.  We usually use Basecamp to track changes and to communicate where we are on tasks with the client.

It sounds obvious, but simply communicating to the client how feedback should be sent can save a ton of headaches.

Lack of resources on client end

Building a website is a lot of work.  Once we turn over a project to the client for review, the ball is largely in their court.  At that point they are responsible for reviewing and testing the site, getting buy-in from relevant stakeholders and filling any content gaps.  This takes more time, and is a less fun, than reviewing a site map or a design comp.

I’ve worked on projects that were delayed for months due to the client simply not having time to review and compile feedback on the draft site.

To mitigate these sort of delays, we try to be up front at the beginning of the project about the amount of time that will be required from the client during the different phases of the project.  The beginning (discovery and planning) and the end (review) of a project tend to be the periods that require the most time from the client.

Lack of a solid content creation plan

Most people approach the drafting of website content the way college students approach term papers: it is something done at the last possible moment with the aid of caffeine and a hard deadline.  For a website, the content should be one of the first things you work on, not one of the last.  There are a few reasons for this:

  • I’ve written about this before, but content has a huge impact on design.  If text you expect to be one sentence ends up being three paragraphs an entire page layout may need to be redone.  Producing content early in the life cycle of a project, instead of at the end, will prevent expensive and time consuming changes during a project’s review phase.
  • People consistently underestimate how long it takes to write and edit a site’s copy.  If content is done at the last minute delays are pretty much inevitable.  We have completed sites and then waited for months for the content to get finalized.
  • Once the copy is produced, it can take a long time for the web development firm to drop the copy into the site and format it so that it looks right.  Content delays can cause a chain reaction, with other work held up until the content is ready to go.

To prevent the content from slowing down a project, we try to work with our clients to establish a clear content creation process and plan at the very beginning of a project.