How we built Metric Loop 2.0

As web developers, there’s no phrase we dread quite like: we need to redo the website. About six weeks ago, our CEO, Jordan walked into the office, looked us in the eye, and said just that. Nick and I got that hollow look in our eyes as our brains raced through the consequences this would have. Our development timeline for Helix would need to be put on hold; we couldn’t maintain our coding momentum, and our prior work was getting called out. We had just finished building a really great website a few months prior! Wasn’t that enough? Sure, the content was lacking but it had a great user interface that set us apart from our competition.

So I immediately began defending the current site. It was, after all, a personal attack on my design and engineering, right? I voiced my frustration, I defended what we built, and I bucked any notion of needing improvement. I was throwing a fit. After sleeping on it, I came back with a different attitude. Emotion wasn’t going to get me anywhere. I still pushed back, but this time I was more concerned about the company than my own feelings. I began to see the need for improvement. I began to buy into this new vision. I began to own it. And just like that I was leading parts of the discussion and employing my resources to bring new ideas to the table.

What Jordan brought to our attention was that the existing website was failing to meet our customers’ expectations. It looked nice and worked well, but it didn’t really tell anyone about who we were, what we did, or why they should care — really critical things for a website to do. With this in mind, we took a look at the website from his (and really our customers’) perspective, and tried to understand why the website was failing. After our review, we realized that our content just wasn’t cutting it. We had built the first website quickly to get our name and brand out into the wild, but we just kind of released it and forgot about it. The content that was supposed to populate the pages was never created, the stakeholders involved got busy, and before we knew it, we had a huge disconnect between our customers and us.

Our Vision

Once we were able to wrap our heads around this, we realized that the website didn’t need to just be redone; it needed to be fundamentally torn down to its base assumptions and rebuilt properly using a content-first approach. Before we jumped into wireframes, mockups, and code, we spent some long hours figuring out our collective vision for what the website needed to accomplish. We talked, we laughed, we stared at the whiteboard, and at the end of the day we walked out of the room with the entire company unified behind what our website needed to do. It had to be an educational resource for our users that helped them learn about the technology they were interested in purchasing, while also allowing them to send us detailed explanations of the technology solutions they were interested in.

A New Hope: Content First

With that goal in mind, we were now ready to lay out the website’s content. We started with the content types we wanted the site to have. It was going to need a landing page with featured content, an educational library of resources, an interactive form, some static pages, our blog, and a CMS to manage all of this with. With this in mind, we had our team start working on producing some sample content for these content types. With the sample content in hand, we realized that our learning section would need two separate content types; the interactive form would be much more complicated than we anticipated (plus it would require user accounts); the static pages would be pretty par for the course, and the CMS would need a CRM upgrade as well as some additional features and a navigation rework. Knowing all of this prior to beginning the information architecture (IA) was incredibly helpful. It allowed us to let the content define the website, instead of trying to arbitrarily force it into a defined hierarchy. So our IA was essentially created for us and truly reflected our underlying content, as you can see in photo below.

Wireframes, Mockups, and Bears!

With our IA in place, Nick could start designing the website. He started sketching out the wireframes using some cutting-edge tactile tools: pencil and paper. By drawing each of the content types, he was able to focus on how each content type needed to present its information. As he drew out each of them, he was able to ask the content producers about the assumptions they used to create the content, and have a discussion about how they would translate to the design. Through the wireframes and discussions, Nick and the content producers were able to identify some fundamental flaws and tweak the content and designs to address them. By the end of the wireframe phase, a multitude of potentially project delaying issues had already been dealt with.

Now it was onto the mockups. Nick transferred his wireframes into Sketch, and began to isolate repeatable patterns within the user interface (UI). Using atomic design principles, he began to infuse the wireframes with Metric Loop’s brand. By the end of this process, we essentially had branded wireframes. Nick then took a nice long look at Dribbble, Pinterest, and Behance before returning to the mockups and tweaking them into a unique UI for Metric Loop. Then he took the mockups, and wired them together in Invision to create clickable prototypes to demo with the team and users. After securing the green light from the team and some quick user tests, we were ready to start coding away at a design that truly supported our vision.

Back, Back, Back that Design Up

The first website had a very simple content management system to create blog articles, populate products, and manage employees. Part of the new vision placed emphasis on building an educational resource for common technology issues. We would organize these Topics into Subjects within the Library which looked a lot like our previous implementation of organizing Products into Types and Groups. That would be an easy switch. We also wanted to expand our ability to create single pages which was the same as creating a Topic, so that was also trivial. This pretty much covered the stuff we could reuse. After this, everything would be new development. Oh and we were going to test every bit of code we wrote.

New Development

We started by laying out the new features: customer accounts, relationship management, tagging, document uploads, virtual forms, and form management. These served as the broad strokes of our new development (i.e. Github milestones). Customer accounts were simple enough, just a specialized version of our employees. During this process I wrote up a piece on setting up multi-auth in Laravel 5.2. At this point, relationship management was just a way to view a Customer’s account after they created an account. We also saw tagging as an easy way to indicate some statuses to our sales team regarding each customer: whether they were a good lead, a bad lead, etc. Then, we needed a way to upload documents securely to a Customer’s portal in order to give them a quote or other necessary materials.

Architect Section

Our biggest new feature was the interactive form, which by this point we were calling the “Architect Section”. We needed a way to ask potential customers questions about issues they are currently facing, so that we can offer them the best solution. The first design of this was really convoluted and broke down at different points in the process. We were trying to build a form instance that could dynamically grow and use logic jumps and all sorts of other voodoo. It was overkill. We ended up converging on a simple interface for employees to create groups of questions and a place for customers to answer those questions and save their answers in a form that could be viewed later. The form would save in real-time and encourage Customers who “abandoned” the form to come back and finish it.

Implementing the Design

We had our design and all the moving parts that make it up. Now we just had to create a reasonable roadmap with a feasible trajectory. Part of that trajectory was focusing on creating an API to take advantage of Vue and encourage asynchronous development.

The Plan

We estimated about six weeks for the project, broken up into two phases. The first phase would be two weeks and that included refactoring the existing website to handle the Library section and single pages. The second phase, of four weeks, would encompass all of the new development, including customer accounts and the Architect section. When we finished the first phase, we would push the code to a small sandbox server for quality and user testing.

The neat thing about these two phases is that the Library section required the most content. So by pushing to a sandbox, we gave ourselves a place to put content that we could then seamlessly transfer to production when we were ready.

First Sprint

We estimated two weeks and delivered in one — queue backflip. This was a huge encouragement and essentially gave us an extra week on new development, which we ended up needing. We had already built the website with Laravel 5.2 which, as you may know, has made developing applications and writing code an absolute joy. So with a little re-naming, re-writing, and re-factoring,we were able to tweak our existing features to fit the new vision and simplify our CMS.

First Milestone

We deployed to a tiny server on AWS with Forge. It didn’t have any DNS records so employees were just typing in IP address. to access the sandbox. This allowed us to gather critical feedback on the user interface and any bugs that showed up. Plus, there’s nothing like working with an actual interface to get everyone excited about what we’re building. At this point, we hit our collective stride and every day felt like we reached a new milestone. We each had our own responsibilities to focus on and we really began to complement each other’s skill sets. If we used words like synergy we would say that we epitomized synergy during these past few weeks. Whatever. We worked together. We bought in. We valued each other’s opinions and feedback.

Second Sprint

The second phase was of the website was incredibly fun. It was fast-paced and adaptive. I was heavy into utilizing Laravel and all of her tricks while Nick was knee-deep in Vue and pumping out some incredible components and reactive UI. I would map out the end-point, write the migrations, models, controllers, and format the data. Each part would have a PHPUnit test. Then, I would hand it off to Nick with the test serving as documentation. He would then use the data to create and style mobile-optimized, data driven front-end components with Vue. Using this process, we got so many things done without needing to confer with each other. Of course some issues arose, but we squashed them quickly by just hopping onto the same computer and discussing each other’s expectations. This led to even better asynchronous development because we began to understand our preconceived notions and we could incorporate those ideas and develop around them.

That’s Good But… Vision?

This development and implementation phase lead to an even greater understanding of our new vision. We unified behind the vision of being a great educational resource for customers and providing the best solutions and the best service. We recognized that when a disjointed team tries to share a vision, it begins to create factions that follow multiple competing and self-serving visions. By focusing on unity, buy-in, and respect for each other, we were able to avoid the nastiness that can come from having many insular teams within a company.

Launch

After weeks of hard work, launch day was finally here. We wanted to launch on a Tuesday evening, which was our lowest traffic point over the past month apart from Sundays. So, we strapped on our hardhats and got to work.

Still Content First

We called for a content cut-off in the sandbox on Tuesday at noon. It actually ended up being at 5pm that day, but deadlines always help. How would you get anything done if it wasn’t for that last 5 minutes? In all seriousness, the content cut-off allowed us to focus on what was important. We knew we would be able to update content after we launched, so we focused on the minimum amount of content that would make the launch viable. It;s amazing how much fluff gets eliminated when you have a cut-off. Deadlines are amazing at fostering focus. And can you believe that our development and content writing were done on the same day?

Back to Production

I practiced the migration about 10 times. It involved dumping the sandbox database and restoring it into the production database, upgrading the code base, copying uploaded images from sandbox to production, setting the environment and flipping the switch back on. At first, it took me an hour. I kept practicing and refining the commands; understanding the process better and better. I got it to about 12 minutes. I felt good about that.

But of course. This is the production server, and it has opinions.

I practiced it with the thought that I was going to be on the production server and sucking all the data from the source server. But no, I ended up being on my virtual machine, pushing all the content to the target server. Paths were backwards and I had to proceed with caution. Luckily, I had practiced enough that I was confident in what I was doing and so it was annoying, but not impossible. After about 30 minutes I wrote php artisan up, pressed enter, and hard-refreshed the browser. It worked!

Maintenance

Almost immediately we began identifying bugs and issues and little things that had to be fixed. But we were ok with that. We launched and were on our way to less stress. We built a great platform to showcase who we are, what we do, and how we can help. We tagged that version as v2.0.0, have already deployed v2.0.1 and are on our way to v2.0.2. We’ll add more features to the back-end customer relationship management and tag it as v2.1.0.

Closing

What started as a messy quagmire of hurt feelings, misunderstandings, and disjointed visions, turned into the best thing we’ve built together as a company. Overcoming these initial challenges wasn’t easy. But once we started listening to each other, it became easier and easier to check our egos at the door and put our collaborative efforts ahead of our personal goals. Looking at the before and after pictures below, we think our vision and our unity really shine through this website. We hope you enjoy using it as much as we did building it.

This article was originally published at metricloop.com on August 5, 2016.