Redesigning the Oomph Website: Managing Without Tickets

Redesigning your company’s website is never an easy task. But when you’re a digital agency and you’re redesigning your own website, it somehow seems like an impossible challenge that you will never get right. First, you have client work that will always take precedence over working on your company’s website. Second, you’re a digital agency! This is your opportunity to push boundaries and try out new things that you otherwise may not be able to on client projects. (Not a requirement, but it would be nice, right?) Lastly, even for an agency, we only redesign our website every few years. In fact, I believe the last time we redesigned our website was in 2016. And thus, there’s still that little voice inside your mind telling you that you have to “get it right”.

So how did we go about doing it?

Changing up our process

If I were to classify the Oomph website I would call it a simple marketing and lead generation website. We need a place to talk about ourselves, who we are, what we do, showcase our work, and capture the information of prospective clients. Typically, when we do this kind of work for a client, these projects tend to last anywhere between four and six months. That doesn’t mean that our team is working on the project full time for that period of time. But with the typical back and forth, feedback and approval cycles, and iteration on design and content, it can easily take that long.

While many agencies do or claim to work in an agile fashion, with a project of this nature there are still typically defined phases to the project that work in a pretty standard waterfall fashion: Discovery -> Strategy -> Design -> Build -> QA -> Launch. Most of our projects follow that pattern as well.

Unfortunately, we didn’t have four to six months. Actually, we only had about six weeks, although those six weeks were not consecutive. So we decided that in order to achieve our compressed timeline, our standard process and methodology would need to be set aside. We determined that the best way for our team to pull this off would be to work in week-long design & development sprints where we had a specific set of pages or templates that we were going to design, develop, test and deploy within a week.

We decided that we weren’t going to use our typical project management system JIRA. There would be no tickets, estimates, or time logging. Instead, we were going to use this good old fashioned form of communication called talking. And while none of us were in the same room, we planned to achieve this by having an open zoom meeting all day long that we could jump in and out of at any time. If you had a question or a decision to make, there were no comments in JIRA issues or Slack messages that didn’t get a reply until the next day. You simply said, “I have a question.” Everyone participated in the conversation, we came to a group consensus and moved on.

Week 1: The Pilot

DISCLAIMER: So I will 100% admit that in week 1 we were not truly starting from scratch. Our design team had already been going through a process of developing style tiles for the site redesign in their spare time. Style tiles are essentially digital mood boards that explore color, typography, and other visual elements. Going into week 1 we already had a pretty good idea of what the look and feel would be. But that was about all we knew.

In order to be successful, we needed to have a few things clearly defined before starting. For example, we felt strongly that we needed core tenets that would help guide the process. These would be the pillars against which we would measure success:

• Even though we are remote, let’s treat this process like we are working together in the same room.
• There are no bad ideas! Everyone participates in the process. Designers participate actively in the development process and developers participate in the design process.
• We have a completed product at the end of every day. We made a schedule for the week of what we were going to accomplish each day and stick to it!
• We are shooting for excellence not perfection.

We needed a goal for the week. To help ensure that we were going to stick to that goal we set daily check-ins with our client (the CEO) at the end of each day. We also scheduled a presentation that we needed to give to the entire company at 4PM on Friday afternoon. We determined that by week’s end we were going to:

• Decide upon the underlying technology that would power the new site. While we had some general ideas as to what we wanted to use, we weren’t 100% sure and we didn’t really even have any experience working with those tools.
• We wanted a complete mobile responsive homepage. That meant we needed to create wireframes, high fidelity mockups, write copy, create assets, do the development and test it out.

At the end of week 1 we had come pretty close to reaching our goal. We selected, set up, and configured the new site to work with the Contentful CMS and use Gatsby as the front end. We designed the homepage and had most of the coding done. Our designer also created a beautiful new video format to help showcase our work. Overall, it was a major success.

Rinse and Repeat

On the heels of our Week 1 experiment, we received approval to continue the project using a similar format. And while we weren’t able to secure a team to work another five consecutive weeks, the team was able to work for two consecutive weeks and then in a few more three to four day stretches. We stuck to the same format but backed off on the all-day zoom calls to allow the team to focus as much on work as they could. However, we stuck to the core tenet of acting like we were in the same room. Anytime a conversation was required or a decision needed to be made, everyone hopped on a call or made a quick judgement call through Slack. There were no tickets.

When it came time to do QA on the site, we kept track of bugs using a spreadsheet that we prioritized and subsequently used to track the squashing of them.

Overall, in terms of project hours we were able to complete the site including QA and some iteration in under six week’s time. Of course, we have a nice laundry list of tasks to complete and ideas we want to iterate on after launch. But we were able to call it done and we are thrilled with the results!

Takeaways and Final Thoughts

We learned a lot from this process. In fact, my biggest takeaway was the benefits we yielded from not following a standard project management process. It was efficient and effective. We did not let the process get in the way of making progress. No balls were dropped. Even though we didn’t use estimates to gauge the level of effort on tasks, no deadlines were missed. I would even say that our communication was significantly better as a result of not using a ticketing system. We actually talked to each other in real-time and came to gain consensus on decisions faster.

Would this work on a larger scale project? I’m not sure. But there are definitely some principles that I think could be applied and lessons learned. Would it work on a client project? I think yes depending upon the client sponsor and their goals. I hope we get to try someday.

In summary, I think that we live in a world where we are constantly looking towards tools and technology to help improve our efficiency. Unfortunately, those tools can often become a hindrance to making progress and being the most efficient version of ourselves. They also tend to remove the human connection from the building process. And when you are building these products for human use and consumption, why not try to add some human-ness back into the process? You may just end up with a better result in the long run.