Agile Web Design Case Study: A Web Designer’s Point of View
Agile web design sounds nice in theory. But can it work practically? What about at an agency? I tell you, friends, it can work—even at an agency.
And I’m going to prove it. I’ll show you how the Agile web design process looked from a web designer’s (my) point of view when redesigning a small security company’s website. You’ll get in my head and see:
- How I worked side-by-side with the content strategist/copywriter and web developer (and the surprising benefits from that)
- Why I made decisions that I did to make the website responsive
- My guerilla tactics for adding local flare to the website to make it stand out from the competition
Here is my story. *Insert Law and Order Theme*
East Virginia? (project background)
My knowledge of Virginia wasn’t what it should have been before being assigned as the web designer to the “Security, Lock and Key” project. I knew that it’s a state whose shape resembles either a passed out duck or a bear sitting on a log trying to catch a fish, and that it should be named East Virginia (am I right North and South Carolina?).
What the team and I did know, however, was security. We’ve worked on more than a few security companies in the past and were both enthusiastic and confident that we would make this project a great one.
Having served the city of Roanoke for over 40 years, we found Security Lock and Key (SLK) to be familiar to the city’s residents and, better yet, genuinely loved by it’s customers. But it wasn’t all sun, fun, and 88 foot high neon stars in Roanoke.
You got some ‘splainin’ to do (the problems)
Customers thought the company only offered lock and key services despite being a full service security company. Ironically enough, their website at the time actually happened to list all of their services, but that was also part of the problem.
Old SLK homepage. Burger joint or security company: You decide.
The navigation listed a multitude of actions that were either too specific, not in line with the company’s direction or simply unnecessary altogether. Indications of where the user should go were non-existent. So you were forced to poke through each page of the site until you found the right content.
Unfortunately, when you found the content you were looking for, it was either saturated with an intimidating amount of detail or so sparse that there wasn’t any benefit to reading it.
Mobile problems aplenty
Tablet and smartphone users had a hard time using the old site since it wasn’t formatted for smaller resolutions. This resulted in a multitude of problems:
- Hit-areas were cumbersome to use because they were too small.
- The navigation required that the user move their mouse over a menu item in order to reveal additional items. This translates poorly to touch devices where hover style actions are not supported.
Old Security Lock and Key service page on an iPhone 5.
Let our powers combine! (content, design and development workin’ together)
During roadmapping, we made sure that we allowed time for the entire team to meet together and discuss the website’s UX.
So the content strategist/copywriter, web designer (me) and web developer huddled around a warm whiteboard to hold a UX (user experience) meeting to discuss possible solutions to the issues we were facing.
Collaborating together like this helped in multiple ways:
- The content strategist made sure the business’s project goals were kept in mind and helped established a content hierarchy (what information is most important).
- The designer and developer helped put that content hierarchy into a page format that made sense for desktop and mobile.
Content strategist, designer, and developer whiteboarding out the home page.
Right away, we knew the information architecture needed to be pruned and consolidated into logical groups to help slim down the number of choices users have to make.
By offering fewer choices, we’re helping guide the user to the proper information rather than giving them a whole mess of options to choose from up front.
Without getting too in depth, this tactic is a solution which abides by Hick’s law, a law stating that the more choices a person has, the longer it will take them to make a decision. This is also referred to as “analysis paralysis”, or the inability to make a decision as a result of having too many choices. This topic is frequently discussed and supported by numerous research reports.
On the other hand, you also don’t want too few choices. It’s a delicate balance.
Far fewer choices on the new homepage. It’s clear what each service is and who it’s meant for.
We also needed to remedy the fact that SLK’s copy was focused on residential clients despite having a commercially dominated client base (about 80%). We decided to write for the majority audience (instead of both audiences) in order to make our copy more relevant to our target audience. This helps cultivate the right audience and convert more users into leads.
And just because we love our jobs more than Batman loves destroying city property and perfectly good lamborghinis, we didn’t stop there.
The outcome of our concept—SLK’s new home page focuses on business security solutions.
It all comes down to monkey fingers (responsive design fun)
The site needed to be responsive which (as a designer) means I have to pay special attention to usability for mobile devices such as tablets and smartphones. Unless you’re into lengthy papers about 3D models of monkey fingers and guidelines on optimal touch target sizes, you’re just going to have to trust me when I say I’ve done my homework.
Seemingly all reports on the subject conflict with each other. So I decided to err on the side of caution and make my hit areas as large as I could without looking ridiculous (while still taking the importance of the visual element I was working with into consideration).
I believe this practice is a sound one since it adheres to Fitts’ Law. It’s a reliable model that proves that the larger and closer an interface item is, the faster a user can touch (or click) it.
Mobile view of part of the home page. Everything around the image and wording is tappable.
Guerrilla tactics for adding local flare
Since SLK had a solid reputation, a well-known name, and pride in it’s city of Roanoke, I thought it’d be fitting to represent that with a photograph of Grandin Village, a historical district in Roanoke where some of SLK’s current customers reside.
New SLK home page with a non-istock image of Grandin Village.
Now, just because you sometimes picture yourself with a bandana around your face, scuttling atop moving trains, stealing random pictures of cats, Bill Murray and Neo from the good citizens of Internetsville, doesn’t mean that you can. Contrary to popular internet practice, copyright laws still need to be followed.
Finding a picture of a relatively small town on a specific street from a specific angle that’s legal to use isn’t the easiest thing in the world to do. I found pictures of wheat, trees, Sandra Bullock, and just about everything else related to Virginia except for the thing I wanted most.
After a little searching around, I came across the Tumblr blog of photography enthusiast Eli Exline. I saw that he had taken some really great landscape photos of Roanoke, which sparked my interest enough to contact him about helping me with my predicament. He obliged, and began to work with us on obtaining the shot we needed.
Personal space is for astronauts (how we worked side-by-side)
After dunking our brains in liquid nitrogen to dissipate the heat generated from all of our awesome ideas about how we were going to help SLK, we got to work on our steely warm laptops with enough passion to make passion fruit seem like normal fruit by comparison.
The layout of our office already facilitates open conversation. So we traditionally ask questions and make on-the-fly decisions about projects by either spinning our chair around, getting up to talk to our team, or in the event that they’ve cocooned their head in their watermelon sized headphones, by sending them an instant message.
Usually it’s quick and easy, but I found there’s something missing here. It’s a small detail, but I think it made a big difference.
The first couple of days, we worked on SLK at the same table, side-by-side, the whole day. This helped us make “micro decisions”, or decisions that are made by asking questions you otherwise wouldn’t have asked if you were working at your desk isolated from your team.
Sometimes you want feedback on something you’ve designed because it might inspire you to create something else. You certainly don’t need it, but the point is you may get to your decision faster just by having other people’s ideas thrown into the mix. It doesn’t matter if the person next to you has anything to do with your discipline because all they’re doing is keeping your brain alert and stirred up with new ideas. Also, sometimes they offer to bring you a Diet Coke when they get up, which is great. Because Diet Coke is a delightfully refreshing beverage containing potassium benzoate, my second favorite food preservative right after calcium propionate.
The fact that you’re sitting at the same table as your team also means you’re talking at a pleasant Bob Ross volume level (as opposed to speaking across a room filled with other people trying to work).
You also don’t have to worry about whether you’re bothering your team since it’s clear they’re dedicated to working on the exact same project as you just by being in the room (and if another project does start distracting someone, you can keep each other in check).
And since we have a conference room with a glass wall, it can also deter others from interrupting you because they can see that you’re busy interacting with your team. You don’t have to have a glass wall for this to work, but It’s highly recommended because normal walls tend to be opaque.
Even how you’re sitting in proximity to someone can be advantageous. For instance, I noticed when sat next to our team’s coder, I could see things in my periphery on his screen and make calls that otherwise wouldn’t have been made until much later. I could catch things like spacing that wasn’t being coded at the size I wanted, in real time, as opposed to catching it once he’s finished. Conversely, he could catch me as I was creating the layout for the site and let me know that if I made “this one small change”, it would make his life much easier later on.
More than a couple times my team also glanced over to see what I was doing and could suggest better ideas than the one I was currently trying to create. It felt like a very effective and simple way to collaborate.
Freshly grilled code
As our content strategist/web copywriter, Chase was busy wafting away the smoke emanating from his conflagrant keyboard as a result of his faster-than-light typing speeds, I was finishing the remainder of my designs. And our coder, Curtis, was orchestrating the construction of the pieces required to build our grand opus.
Coding is generally the longest part of the process since it’s the most complex, but we needed to get this project done quickly and efficiently.
Typically we install a CMS for our clients which includes a whole robust set of features. But the size of SLK’s website didn’t warrant the time and complexity that such a system would require to develop and manage. Instead, we opted to use a free, open source web architecture called DocPad.
DocPad, unlike CMSs, uses files to store it’s information instead of a database. All websites used to run solely on files in the past. But nowadays it’s rare to find a site not using a database. So why use an old technology? Because it works, and it works even better with DocPad.
In addition to the natural benefits of using a file system driven website (such as not requiring all of the process heavy complex logic which would normally be required to talk to a database) we made use of DocPad’s ability to generate static pages automatically from separate, easily manageable content files. This allows us to use, for example, a single template file for any number of pages we’d like without having to actually manually build each page ourselves (a long, tedious affair which would put even the greatest of developers into perdurable catatonia).
Wrapping it up like a mummy with a burrito
After all the design, coding and content was complete, it was time to start wrapping it up. In addition to our standard testing procedures, we also opened the site up to peer review via BugHerd, a polished and feature-rich online bug tracking tool.
Thankfully, due largely in part to the close communication of the team throughout the project, there weren’t any changes significant enough to cause any delays. Most changes were minor font and spacing adjustments, which were easily cured.
Houston, mission accomplished
In the end:
- Each phase of the project was completed on time
- The site was launched with ease
- The client was happy with our work.
Working on this project was a genuine pleasure since I worked with a team and client whose sustained momentum and enthusiasm kept me inspired and delighted the entire time
I think this calls for cupcakes.