After months and months of planning, research, design and actual development the new CaseIT Website has launched. This will be a longer post (and it may be boring for some of you) but it's a thorough breakdown of the process we went through to go from the old CaseIT Website to the New CaseIT Website.
Breaking it Down
Building a new website for CaseIT was not only about updating the CaseIT website with the new brand and modernizing the look and feel of the website. Our goal was to improve the CaseIT Web Experience. But how exactly do we improve the CaseIT Web Experience? What is there to improve? Why are we trying to improve it? How are we going to do that? Here is a not so secret tool we used to guide us through these questions and process. It's called the UX Project Checklist created by Andrea Soverini.
We first looked at other Case Competition Websites, how they solved problems, what can we learn from them and what can we adapt. From there we looked at our Analytics to try and identify issues. The Nielsel Norman Group suggests 3 uses for Analytics in UX design. We used it mostly as an investigative tool and discovered that many of our visitors were coming to the site and immediately dropping off without actually clicking any links. This is often referred to in percentages as the bounce rate. For example, if half the people browse your site without clicking on anything, that is a 50% bounce rate (it gets more complex but we won't get into that).
Plan, Explore, Communicate
We've now identified our problem, we've looked at the feedback available (we didn't really have a place for visitors to leave us feedback). Our next step was to actually talk to some real people as to what they do on the CaseIT Website and what they use it for. From there we developed our three personas.
Designing for the User
The purpose is to create scenarios and stories based on how our three personas would use the CaseIT Website. From there we develop a hypothetical journey as to how each user would interact with the site. The creation of flows, not pages often yields better results. Where are they coming from? Facebook? Email? Google? What is their objective? To keep this short we'll look at the example of a potential competitor.
By creating a scenario and a user story, we're able to determine what potential competitors will want to do when they visit the CaseIT Website. This would likely include: Finding more information about the competition such as format, rules, and schedule. As our competition is focused upon students from outside our local city, they might also want to know about the Event Venues they will be going to and also about Vancouver, BC. For the competitor that really wants to prepare, they may also want to look at a history of cases that were in previous years and hear what past competitors have to say. This allows us to have a better understanding of what the Competitor may want to do and what we can do to try to adapt the design of our website towards them.
Red Routes (the things everyone wants to do)
But what about the other users? What about the casuals? For example, what is one thing everyone wants to do on a weather website? Probably check the weather on a particular city or area they are in (or planning to go to). This is known as a red route. The things everyone wants to do every time they go to your site. For us, we determined that our red route is finding out what's new. Every type of visitor to our website has a good chance of wanting to know what's new with CaseIT. It's also this new content that allows for our users to keep coming back, looking for more. Red routes allow for a user to not just come to our website once, but have them return to the site more often.
Sketch, Wireframe and Prototype!
Once we have determined who we're designing for and what things we've classified as important we sketched, wireframed and prototyped. I won't get into why we do this (there's a lot of blog posts out there that already do this better than I ever could) but prototyping allows for rapid idea and iterative ideation of form and testing, with heavier emphasis on the testing. Just because we've determined and done our best guessing at trying to figure out what the user wants, it may not be what they need. Testing allows us to prove whether our guesses weren't just guesses and that we're on the right track.
There's a whole lot more after this...
Eventually there will be a "part two" that talks about how we turned the wireframe into what you see on the website today. If you look on the UX Project Checklist we've only gone through step 9 of 27. So as you can probably imagine, it's not a short process. Even though we've launched, we're still not fully finished. It's an ongoing process and there is not a single perfect solution. You don't have to check off every box to get it, but checking off every box also doesn't mean you'll get it.The checklist for us is to act as guidelines to move us further in the right direction. This is why we've included a feedback button at the bottom of every page.
GIVE US FEEDBACK
If you've gotten this far, you must have some interest either in the way things are designed, made or you are just really bored. But feedback is important and it allows us to get to where we want to be, improving the CaseIT Web Experience. So if you haven't already, explore the new CaseIT Website and let us know what you think.