A blog by the Brick Factory The Brick Factory
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.

The Web Development Process Explained in 11 Animated Gifs

Building websites is hard work. And a lot of it isn’t that much fun.

To help explain the process, we’ve put together this tongue and cheek post that explains how we typically feel during the various stages of a web development process.  Since we build sites for clients, this post if from the point of view of a web development firm.  Clients will likely experience similar mood swings, but at different points.

(1) Award of project…

excited will ferrel elf

As a web development firm, having people hire us to build websites is a pretty critical part of our business model.  The process of signing up new clients can be time consuming and stressful, so it always feels great to get a win. (more…)

6 Things

6 things you probably didn’t know about the Brick Factory

We’ve had a good first half of 2014. We sent an update on what we’ve been up so far this year to to our email list, and wanted to share it here on our blog as well.  Enjoy.

email

drupalcon

23 Takeaways from Drupalcon Austin

Chris, Mike, Ron, Shane, Teddy and I spent last week at Drupalcon Austin.   We learned a lot, and ate our fair share of Mexican food and BBQ.  Following is a list of our key takeaways from the trip.

(1) Drupal 8 won’t be released until sometime in 2015.  During a Q&A with Dries Buytaert and other key Drupal 8 contributors, they advised against using Drupal 8 if you have a project you need to ship in the next three to six months.

(2) In the same panel, it was mentioned that it took a year after Drupal 7 was released for the majority of contributed modules to get updated.  The goal is to cut that time in half, to six months, for Drupal 8.

Drupalcon

(3) When Drupal 7 was released, support for Drupal 5 was dropped immediately.  Assuming funding allows, the plan is to perform critical security updates to Drupal 6 for one year after the release of Drupal 8.  This is huge, as it will give the hundreds of thousands of sites run in Drupal 6 more time to make the transition.

(4) Drupal 8 will not support anything lower than Internet Explorer 9.  This got a big cheer from the crowd.  Drupalcon attendees are not big IE fans.

(5) 12% of the 100,000 most popular websites on the Internet are powered by Drupal.

(6) Paraphrasing Nica Lorber from her content session: “Clients underestimate the importance of content and won’t pay for it.”  So true.

(7) Another tidbit from Nica: People read 20% slower online.

(8) Nica also made the point that flexibility is overrated when it comes to content.  She recommends developing structures for content with clients and sticking to it:  make decisions.  I couldn’t agree more.  On the web constraints actually help.

(9) If you want to see the bats emerge from the Congress Avenue Bridge in Austin, you’ll have to show a bit more patience than our Brick Factory team.  We waited about 45 minutes before giving up on them.

Congress Avenue Bridge

(10) Ron heard a lot about Docker, the open source project that containerizes applications. He wrote:  “Docker is really useful for managing and deploying applications and the software/libraries needed within the same or among different environments. Even the new Red Hat Enterprise version distribution that came out two days ago supports Docker.”

(11) Our front-end development team loved the “My Brain Is Full” session.  Teddy wrote: “This session summed up how I view web development right now. Lots of technologies sprouting up at once that are difficult to keep track of, with the hope that these front end development processes will be streamlined over time.”

(12) The “Twig Playground” session was also popular with our team.  Teddy again: “Morten DK was probably my favorite presenter because he did a good job of pinpointing aspects of Drupal theming that I don’t like and he cursed a lot. It seems that a lot of these issues will be gone once Drupal 8 comes around.”  Shane: “Twig is a great addition in Drupal 8.  This will make Drupal more secure, and it will also be more familiar to people who are switching from other platforms.”

(13) If you love music (vinyl in particular) and are in Austin, don’t miss Waterloo Records.  Bring your wallet.

Waterloo Records

(14) Many of the Drupal firms we talked to have done a full embrace of Scrum, an agile software development framework. For many this has simply become how they do their work.  I’m a bit skeptical of whether this will work for us across the board.  I tend to think that the right methodology can change from project to project.   From my conversations, Scrum seems to work best on projects with scopes that are less well defined and with clients who have time (at least ten hours a week) to be involved in the website build on a daily basis.  If you want to learn more about Scrum, check out this session.

(15) Ron and Chris are much better at their jobs than at riding a mechanical bull.  Ron and Shane are both pretty good a ping pong though.

Drupalcon mechanical bull and ping pong

(16) Great quote from Jordan Hirsch’s 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.”  Yup.

(17) The audience shared Jordan’s pain when he talked about how destructive hidden requirements are to the web development process. Like the Salesforce integration you find out about two days before launch.

(18) I loved Adam Edgerton’s presentation on scaling a Drupal firm.  One key point he made was that profit doesn’t necessarily scale along with revenue.  A digital agency might make the same profit at $10,000,000 in revenue as they did at $4,000,000.  He mentioned that once you get over 25 people you start to need process.  At that point you are no longer a tribal company.

(19) An emerging trend is the use of Drupal as a backend system for content management with frontends that are 100% outside of Drupal.  In particular, a lot of firms are using AngularJS on top of Drupal.

(20) Chris went to a session that talked about the importance of developing processes that are non-blocking.  The web development process goes much more smoothly when folks aren’t constantly taking breaks to wait on delayed deliverables/approvals.

(21) Ron is excited about the configuration management software Ansible.  He wrote: “I was sold when I heard that it is agentless, so you don’t have to install anything on the servers. Besides that, it uses current standard protocols and syntax and can also handle app deployments. It seems like a dream come true.”

(22) I can’t say enough good things about the tacos at La Condesa.  Probably the best tacos I have ever had.  Go now.  We didn’t take picture of the tacos as we were too focused on eating them, but here are some other food porn pics from the trip.

Tacos and BBQ in Austin

(23) Drupalcon will be in Los Angeles in 2015.  We’re fired up, ready to go.

3RD_ROUND

Our New Website

We quietly launched our new Brick Factory website last week.  I’m really proud of it.  I think it is a true reflection of who we are and what we do, which is tough to pull off.

When web development firms build sites for themselves, the instinct is to show off.  To overdesign.  To throw in every bell and whistle.  “Let’s implement all the ideas!”  The resulting sites often look like they are designed for other web designers/developers, as opposed to the actual audience, prospective clients.

As a firm that preaches simplicity and talks a lot of audiences and conversions, it was important that our own site reflect the work we do for our clients.  It is a real tribute to the talent of our staff that we were able to create a site that is simultaneously simple, completely unique and beautiful.

The launch of the new site also represents the Brick Factory entering its next phase.

As a group, we’ve focused the last year on getting better at what we do a little bit every day.

We’ve embraced new processes and technologies.  We’ve fixed some structural issues we were having.    We’ve invested heavily in the development of some new products we will announce soon.  All while doing some incredible work for our clients.

So please take a look at the new site and let me know what you think.  Also be sure to check back in on us, as we have some great things in store for the rest of the year.