Date published: February 15th, 2016 | By Matthew
Full Analysis of New Website Design and Development
A couple weeks ago we launched our new website. Pretty exciting stuff.
This post is a full analysis of the entire design and development process. It's a little geeky.
Here were the eight parts of our design and development process:
- Background Research
- Setting Priorities
- Choosing a Designer / Developer
- Content Creation
- Feedback and Beta Testing
Let's dive in.
By background research, I mean "get a lay of the land". This started a long time ago.
As I think about it, we really did three types of research: took note of stuff we liked, monitored trends and asked other people.
(I’m using the word “research” pretty loosely here.)
We Took Note of Stuff We Liked
Pretty much, this started the day after we launched our old website in 2014. All we did is, during our normal e-routines, we noted websites we really liked and the features we wish we had. Pretty simple.
We Monitored Trends
We also monitored trends in design and development. Here's an example.
Did you know that mobile is a big deal? Yes, you did. We learned this a few years ago when a marketing consultant friend told us.
But how big a deal is it? Let's look at a chart:
This chart is titled "Time Spent per Adult User per Day with Digital Media, USA, 2008-2015YTD". I've circled in red what to look at.
Along the bottom, you’ll see the years from 2008 to 2015.
Look at 2008. In that year, Americans spent 2.7 hours per day online. Of those hours, 0.3 were on mobile. That’s 11% — not very much.
Now look at 2015. In that year, Americans spent 5.6 hours per day online. Of those hours, 2.8 were on mobile. That’s 50%.
That’s a lot. That means that half the time people are on the web they're on their mobile device.
"Hmm," we thought. "We didn't realize the numbers had grown so quickly."
Partly, this was because our Google Analytics put our mobile traffic at just 25%. Why is that? Well, maybe people would have spent more time on our mobile site if it didn't s*** so much.
Which brings us to responsive design. Our old website had responsive design. We thought that meant “we’re good”.
We were wrong.
As you know, responsive design means a site responds to the size of the screen — a big screen shows one design; a small screen shows another design. For example, if you’re viewing XYZ site on mobile, the headers, text and images shift around Tetris-style to accommodate the mobile screen.
Our old site had responsive design, but it didn’t look good enough to accommodate 50% of our traffic, no way.
In fact, whenever we made changes to the site (like pictures, content, etc.) we only looked at the desktop version, never the mobile version. Big mistake.
As it turns out, there’s a lot that goes into the design and development of a site to make sure it looks great on mobile. Responsive design without intent is not good enough for half your traffic.
So, because of this trend toward mobile, we made “looking / working great on mobile” a priority.
We Asked Other People
The third thing we did was ask others. Anybody who had a site, we asked them.
Advice came from some surprising corners. For example, my Uncle Jeff owns a business in Boston that connects vacationers with home rentals on Cape Cod— nothing in common with summer camp, but he knows a ton about web development and he and my Aunt Joan were a great resource.
We also asked the Summer Camp Professionals group on Facebook and they had some great ideas (check out this post for their helpful suggestions).
And that's it.
It was time to set our priorities.
Here’s the most valuable thing we learned about website development: you can’t have it all.
Building a website is about making trade-offs. You can’t be all things to all people. Instead, you have to set your priorities and then allow yourself to make decisions according to those priorities.
When we learned this, it really changed our perspective and made our decision-making process easier.
Here were the three priorities we established for this site:
- Looking / working great on mobile
We chose simple in part because of personal preference, but mostly because of Steve Krug and his wonderful book Don’t Make Me Think!. It was easier to follow Krug’s advice with a simple design.
Also, we learned about the paradox of choice. Intuitively, giving people more options seems smart, because people prefer having options to not having options. But, interestingly, the science shows that having more choice tends to overwhelm people. And this certainly holds true for website usability.
We chose fast because of the science around load times and conversion rates. Higher load times = lower conversion rates. In plain English, people have no patience for slow sites. Pretty straightforward.
My favorite part of our priorities is that they reinforce one another: it’s easier to build a fast site when the design is simple, and it’s easier to make a site look and work great on mobile when it’s simple and fast.
Choosing a Designer / Developer
This part was relatively easy.
There's a startup we've been following called Crew. If you need to build a website or an app, Crew connects you with capable designers and developers.
They (Crew) understand how scary it is trusting people you've never met with something as big as your website. So what they do is they go out and handpick designers and developers (a few hundred is my guess, but I really don't know) and then connect you to their pool.
For this service — the matchmaking — they charge 15%. Seems stiff, but for us it was worth it.
So we went to Crew, signed up, paid the $100 yes-we-are-serious deposit, and submitted a brief. Here's the brief.
Six applicants responded to our brief. We interviewed three of them over Skype.
During this matchmaking process, we were introduced to a new CMS called Statamic. Statamic is a flat-file CMS (whatever that means) so it's lighter and faster than Wordpress (which we used to be on).
We did some research on Statamic to see if it was a good option for us, or not. Here's what we found.
The advantages are, it's lighter and faster.
The risks are (1) if we don't like our designer / developer, the pool of alternatives is much smaller than Wordpress, (2) the add-on developer community is much smaller so fewer options there and (3) there's a chance Statamic won't be around in a couple years (just because it's new).
Ultimately, we decided that moving to Statamic was a good idea and worth the risk.
Originally, we told Crew we had a $5,000 budget but we ended up spending $8,000 to get the team we wanted — about one third of the amount I wish I had (budgets!).
We went with our first choice, Series 8, a small shop in London.
The way Crew works, when the contract is signed, you wire the entire amount to them and they hold it for you in escrow. The designer / developer (Series 8) then splits up the project into phases (two in our case) and requests funds upon completion of the phases. Crew doesn't release the funds until they get approval from you. Seemed smart, and it worked great.
If I think about the nine-month process in terms of excitement level, it definitely peaked during the design phase.
Mario, our guy at Series 8, worked with us over software where he'd put up wireframes (of page templates) and then we'd go back and forth until it looked the way we wanted it to. Mario and his colleagues were very good, and it was thrilling to get glimpses of what our new site would look like.
As soon as the design phase was finished, the excitement level plummeted and, honestly, it stayed there until we launched.
Development was pretty boring. Basically, we just watched the developers build our site. It took a lot longer than the design phase, and my role felt a lot like nagging: "move that here please" or "make this look like that" or "no that's not quite right".
To Mario's credit, he was patient and gracious.
Content creation was also boring. Lots of writing, revising, editing, finding images, sizing them properly, uploading them, etc.
The exception (the only not-boring part) was the homepage. The challenge was to make the ultimate case for Longacre Camp, and I thoroughly enjoyed it.
Feedback and Beta Testing
Feedback and beta testing are an essential part of launching a website. Having said that, they're not very enjoyable.
After putting hundreds of hours into a project like this, it was tough to hear criticism of the site, even constructive criticism, even after I expressly solicited it. Still, all the feedback and testing helped us (a) work out a lot of the kinks and (b) say things in a clearer way, so it was worth it.
There were three parts to our feedback and beta testing. Part 1, we put up the new site at beta.longacre.com (so new visitors to longacre.com wouldn't be bothered). Then we blasted out that url to our email list and asked for help. You never know who likes beta testing and, right on queue, we got a bunch of responses from people who love us but still have that all-important outsider's perspective. Their comments were superb.
Some of the funnest responses were from people who had never beta tested before — didn't even know what the word beta meant — but loved the idea and jumped right in.
Part 2 was user testing. UserTesting.com has a freemium feature called Peek. Peek gives you three free user tests per month and we used those.
In Part 3, we used Feedback Army. You tell them what you're looking for and then a bunch of randos give you feedback. It was worth the 40 bucks.
Three of them:
- The whole process took nine months. I projected six months. I generally feel confident about my projections. I got this one wrong and I feel naive.
- I was surprised that the second half of the process — from the completion of the design phase through to the launch — was such a chore. I guess I expected the creative process to be more rewarding.
- There's still lots to do. Series 8, thankfully, has agreed to stay on at an hourly rate. My guess is we'll continue to make modifications until we decide to build our next site.
All in all, we're really pleased. Hope this helps. Good luck.