Building a Better Mouse Trap, Part 3

While we did a good job of executing the discovery and define phase we decided to bid out implementation. This cost us time as we had selected Drupal as our web cms platform, we decided it made the most sense to go with a shop that did nothing, but Drupal.

I had worked with a few different open source web cms platforms in the past (WordPress, Concrete5, Zope/Plone), but had not managed one that would be multi-site and multi-language.

Like most things these days, data is the key. Any content management system is driven by the data to build the relationships that render your content. The better organized your data, the more you can do with your content.

Unfortunately, our data was not well organized. We had different categorizations of products in different business units and these were not contained in our database, but instead in print catalogs. Our products were sometimes named individually, sometimes by product line, and sometimes not at all. The product descriptions were often internal short-hand if they existed at all. And because some of our products are disposables and accessories and others could have been launched ten years ago or more and could still be in service by different types of facilities, our list of products was over 20,000.

Since we finished Discovery in April/May time period and then bid out, did vendor selection, and got to contracting late June we had the misfortune of trying to get the contract terms resolved, internal sign-offs made, and initial payment out the door over the summer. As a result our window from when we selected a vendor to when we began work was close to eight weeks.

In a project with a reasonable time crunch, we wanted to launch end of November, this was a costly amount of time.

The benefit of that window was that I spent all but my week of vacation working on the data and discussing a plan with the vendor. We decided to first conduct a technical discovery with a milestone of a revised project plan and estimated hours. This would essentially review our discovery and my data and how the data would relate to the wireframes and functionality we wanted from the site.

How to organize 20,000+ records? I was one year and a little less than six months into the job. I had a decent sense of the businesses whose marketing teams were based in my building, but not as good of one for the others outside of it. In our initial discovery we had discussed the presentation of products on pages. We decided that not all products required a full web page, but at the same time we still wanted them to have a presence, so we came up with the idea that products that didn’t get a page would be able to be found in a “Product Selector”.

The Product Selector was really just a filtered search on a content type of “Product”. It could be further filtered by the procedure it was affiliated with, its categorization and sub-categorization, and the technology it employed. The difference is that some items would only have a one sentence blurb and then there would be a call to contact either inside sales or customer service.

One of the goals of the site as outlined in the initial discovery was to present our complete suite of products. In the push to promote our capital products, our single-use and reusable devices often were not top-of-mind. To accomplish this we thought again about what we were selling. At the heart of our offerings is the endoscope. There are two affiliated components, the devices that go through the scope and the equipment that the scope plugs into to provide light, record images, etc.

Affiliated with the equipment are non-medical accessories, such as the cart, bottles, tubes, connectors, bottle caps, monitors, keyboards, batteries, etc.

So now we had a top level set of groups: Scopes, Equipment, Accessories, and Devices. These worked very nicely for our one business group, but we had to really extend these categories to work for the others.

To show how the products were associated we created three types of product pages. If a Scope was the type of product for a given page, then there would be three featured related Equipment pieces shown and three related featured accessories on the page and then on the right sidebar we had a widget that would list all related equipment and all related accessories.

The first trick was then figuring how all of these products should be sorted into these categories. I essentially performed some basic update queries, scanned the preview of results and then updated the group field. This worked for a while and allowed me to get a fair amount of records sorted, but it was still a large record set.

The first big filter that was applied was the acquisition of financial records. I matched sales information by product ID and created some cut-offs based on total sales and units sold. At one threshold, I indicated these products should be included in the product selector and at another threshold I indicated these should receive a full webpage.

I manually added some new product releases, but overall this made my job of applying categories and subcategories much easier. I want to say at this point there were roughly 2,500 products instead of 20,000+.

The second trick was determining which products were affiliated with one another. In our print brochures we often included a blow-out diagram of how our equipment connected to other component pieces, but again, I couldn’t find a database that contained this information, only print pieces.

The solution to this problem was to leverage our other site goal of presenting the products we make available that could be used in a procedure. In this way a physician or surgeon on our site could select their specialty and be presented with featured procedures. Each featured procedure would have videos and below the video player featured products (while the number could be unlimited, we decided 6-15 in columns of three worked best from a user experience perspective).

Related products then became any product that was in a procedure was related to all other products in that procedure. This allowed us to group products due to their being included in a procedure together.

The next problem, which I’ll address in the next post, is that we also didn’t know which products were used in which procedures. For that I had to rely on the product managers.

As I continued to work on updating and validating my data, we got the agreement signed and began discussing how the data would be used and what we wanted to accomplish. The technical discovery concluded and the implementation company added a few hours, but they were nominal. It was time to configure Drupal.

Since we had an internal agency, we were going to do the design and front-end coding on four or five main page types, the implementation company would “drupalfy” them and we would then build out the rest of the site pages based on those templates.

Also, because we were all new to Drupal, we had a one hour weekly call with our implementation company and IT team to talk through how Drupal worked and what custom work was being done. We also secured a service agreement and training from Acquia, though in hindsight we should have done this much earlier.

My goal was to have all content complete by 11/2/12, but for a variety of reasons we missed that date by about ten days. I’ll address content and content review in my next post.


One response to “Building a Better Mouse Trap, Part 3

  1. My goodness, this sounds exhausting. Hang in there, my friend. You can do it.