How We Built and Tested a New Website in Five Days

PMG’s website is about to undergo a refresh.  We want our site to better reflect the innovation, technology and incredible work we produce for our clients.  To shake things up, we decided to try a different approach to tackling the project.  We discovered the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days and it piqued our interest.  Could our PMG website team carve out five entire days to revamp our site to better reflect our company?  Yes… yes… yes we can.  So we picked a week, got all six people on the PMG website team together and we dominated the Boardroom for five days.

I should clarify that we didn’t build a fully designed and functioning website in just five days, but we did build a very realistic prototype in five days.  Here’s a recap of the book to help explain.

The sprint is a unique process for solving tough problems by researching, sketching, deciding, prototyping and testing a solution in just five days.  The real benefit is that you can get real, immediate feedback from your target audience at the end of the sprint instead of waiting weeks or months to build a minimum viable product (MVP).

Day 1 – Dig Into the Problem

Define the long-term goal of the project – ask: “Why are we doing this project? Where do we want to be in six months, a year, or even five years from now?”

Make a map – create a simple diagram that will show how customers move through your product or service.

Ask the experts – interview the experts on your team, one person at a time, to gather more information about the problem.

Pick your target audience – choose a customer type and a focus from the map.  This will narrow the focus of what you’re trying to accomplish for the rest of the sprint.

Day 2 – Sketch Solutions

Lightening Demos – review inspiration from other products or services. Each person brings three examples of other products or services that solve a related problem well.  Use these as inspiration for crafting solutions later in the day.

Sketch solutions, individually – group brainstorms don’t work. Check out this article for the all the reasons.  Instead, everyone sketches solutions alone.  There are several steps to this process, but the rest of the day focuses on each person individually sketches a solution.  Nobody sees these solutions until Wednesday.

Day 3 – Decide on a Solution

Review the sketches – the sketches are anonymously taped to the wall and everyone reviews them silently.  The goal is to not know who did which sketch so that you’re not influenced by the author.  You vote with small stickers on the parts of a sketch that you like the best.  This method discourages groupthink and sales pitches.  The ideas stand on their own.

Decide on a winning solution – the winning concepts will quickly emerge as you see a heat map of the stickers on the best ideas.  The Decider of the project gets the final say on which solution(s) are chosen for the prototype.

Create a story board – you take the winning sketches and combine them together in a cohesive story.  This outlines all the steps the user would take as they use your product or service.  This story board provides the details for what you need to build into your prototype.

Day 4 – Create a Prototype of the Solution

Build, build, build – the entire day is focused on building a realistic prototype of your willing solution based on your story board.  The book highly encourages using Keynote to create the prototype because it’s a robust tool that get the prototype “close enough” without being pixel perfect.  We opted to use Adobe Muse because it was easy to use and it allowed us to create a more realistic-looking website prototype.

Your team divides and conquers.  Each person has a specific job to do to help the prototype.  You’ll have a few “builders” who are focused on building the pages within the tool you choose, one person writing content (it’s frowned upon to use placeholder or lorem ipsum copy), one person is sourcing images, etc.

At the end of the day, you should have a fully functional prototype that is ready to test.

Whew, this is a hard day but it’s really rewarding to walk way with tangible output of all your hard work so far.

Day 5 – Test the Prototype

This is where rubber meets the road, you get to test your prototype by showing it to five people who fit your target audience.  Five interviews is all you need to reveal big patterns.  This is the most crucial day in the process because you get valuable feedback before you’ve invested weeks or months building the full-blown solution.

You take notes of the positive and negative reactions to the prototype, then regroup with your team and make adjustments to the prototype where needed.

Now you go forth and build the real product if the interviews confirmed that you’re on the right track!  If not, there’s opportunity to revisit your solution and adjust your course.

It was a really fun week that produced an awesome prototype at the end of the sprint.  We have clear direction of what we should build along with valuable customer feedback that gives us more confidence and direction on the path we’re going down.  I highlight recommend the Sprint book to anyone.  The process can be applied to almost any project, problem or opportunity.

Here are our take-aways from the week:

Asking your target audience for candid feedback of a working prototype is valuable.  It confirms if we’re on the right track before investing tons of time and money on a solution we *think* will work.  Instead, we have their candid feedback that helps us see what we did well and were we can still improve.

Having dedicated time with your team to focus on one problem/project rocks!  It was really awesome to get away from distractions and put our brain power together to solve one problem.

Spending a lot of time researching the problem before diving into solutions was important.  Spending more time upfront causes less re-work down the road.  Often times, we like to dive into solutions before we fully understand the opportunity or problem at hand.

People are extremely visual and it’s hard to look past placeholder visuals/designs.  Our prototype was focused on content of the site and structure/flow of the site.  It was not a week devoted to creating amazing designs and branding of the site.  That will come afterward.  So for the purpose of the sprint, we used a lot of placeholder visuals.  This proved to be challenging for people to look past.  In the end, we still got really constructive feedback on our content and site flow, but it was sometimes hard to look past the placeholder designs.

Working together, independently was interesting and productive.  I’m a big believer now in this approach to solving problems.  This is a valuable exercise that can be applied outside of the full five-day sprint process.

Stay tuned to see how our site progresses.  And maybe the next time you think about scheduling a group brainstorm, you’ll try this five-day sprint process instead.