Oh boy, it’s been a crazy week. But not in a bad way. In a good way. In a really good way. A couple of days ago, we went live with our new website.
The process to bringing our website live has been an incredible awesome roller coaster ride with so many learnings and insights to share. So let’s get started.
A history lesson.
Before sharing the latest lessons learned, I’d like to give you a glimpse into the world of Usersnap websites. Since it’s birth, usersnap.com has seen a lot of different website designs, technologies, and content.
So let me give you a bit of history of usersnap.com.
Usersnap.com in mid-2013:
How the website looked like in Early 2014:
…and in late 2014:
Here’s how the website changed in 2015:
Our all new website since Feb. 24th 16:
Yet another relaunch?
So, you might wonder: Why – another re-launch?
Well. Our last major redesign happened in late 2014. That said, our recent relaunch was just a redesign and had nothing to do with the technology being used.
Since the end 2014, a lot of things happened. Usersnap grew its customer base as well as their number of employees. Especially the later factor made us re-think the way we publish our content.
Making it easy for everyone on our team to contribute to our landing pages was our main incentive here.
And since we just kept adding different design types to our existing landing pages, we decided that this is going to be a major relaunch.
The branding goal: Same same, but better.
From a technology perspective, our goals were simple and clear – at least in theory. From a brand and marketing perspective, they weren’t that obvious in the beginning.
However, we knew that a fresher look of Usersnap and our product will help us in the long run.
Dated October 27th 2015 I’ve found this Google document in which we concluded the following goals for the upcoming redesign:
- redesign usersnap.com in order to improve the user experience
- unify the landing page design – currently we have differently looking landing pages out there.
- reduce the amount of landing pages
- each page should solve a purpose (i.e. has a particular user in mind and should serve a particular point in the user’s customer journey)
- deploying new sites should be so simple that everyone can do it.
New tool stack
When having a software – browser based – product, legacy code becomes an important issue over time. Especially since our website and domain usersnap.com is deeply connected with our web application.
And because of that, changing simple and minor things on a landing page, lead to an inefficient process involving engineering power and therefore requiring too many people be involved.
We knew that we had to re-ask a lot of questions which haven’t been asked in the past.
It’s not just that we changed our tool stack because of shiny new tools and toys. The major change in our tool stack was due to our new workflow. There was this clear need that the workflow for changing things on our website must be as easy as possible and must enable marketing people, as well as designers to change things.
If you want to read more about how we set up our new workflows for deploying landing pages, I recommend checking out this sitepoint.com article which I published a couple of days ago.
This article gives you an in-depth look how and why we did certain things in regards to specific tools.
Content first? Design first?
When starting out with a blank page, people persistently start working on low fidelity scribbles and mockups without thinking about content first.
It’s a really hard game to not fall into the trap of sketching, drawing and designing in the first place. At least that’s what I’ve experienced.
So starting out with the content which matters most to us, was one of the first tasks.
(I’d love to show you some of the first scribbles here – however, I am afraid that my writing is too bad to be showing anything ;))
So here’s the path we took in bringing this website live.
As you can see in the chart above, we really tried to focus on the content this time. During the process of designing and launching the site, we re-worked the content multiple times and focused on details as well.
For example, we’ve set up our own dashboard which we only used for taking screenshots of our product.
Learning from our design process
After working on our content and information architecture we continued with prototyping. We created low-fidelity mockups with Moqups.com and collected a mood board with different inspirations and ideas inside an own Usersnap project.
After prototyping, our designer Pavel started to first mockups in Sketch. Sketch is a pretty awesome tool for UI designers. It’s light and easy-to-use.
Learnings from using a static site generator
If you’re an active reader of our blog, you probably know that bugtrackers.io (a side project of ours) already runs on Hugo, a static site generator. The experience with Hugo for bugtrackers.io made us choose it for usersnap.com as well.
However, we weren’t fully aware of the consequences. Bugtrackers.io is a pretty simple website compared to usersnap.com. Making usersnap.com Hugo-ready required us to put our heads together and over-invest in the Hugo setup.
There were a lot of bugs and issues which I guess simply occurred because we used Hugo for the first time for such an “expansive website”.
Become an information & technology architect
Building a website is like building a house. Without a good foundation, you and your project won’t make it anywhere. So, better become an architect.
The architecture comes into place when working on your content. But it also plays a key role while developing and prototyping.
Making sure that your CSS files are well-structured is key here. Only use CSS where it’s supposed to be.
A re-launch is different than a launch.
Re-launching a website is always more complex than launching something completely new. The relaunch of usersnap.com required us to take a deep look into our technological basis and how we did things in the past.
Redirecting URLs, making sure that our product is up-and-running and links are working was a major task.
A checklist of things which had to be checked before going live with Hugo on usersnap.com kept us from going nuts. There are so many things which you probably do not consider as relevant, but which do pop up just before going live.
Here’s how our relaunch checklist looked liked.
Do not underestimate things which you have never done before
During the process of relaunching usersnap.com, we encountered situations which we haven’t encountered before. We used tools which we haven’t used before. And we forced ourselves to set up a new workflow which we weren’t used to.
So there’s a lot of new here.
One of the biggest learnings which we saw, can be found in this factor. Not being familiar with technologies, frameworks or workflows require a greater amount of time and resource than things which you’ve always used to do.
The importance of a proper CDN when relaunching
A CDN (content delivery network) is a system of distributed servers. Those distributed servers enable you to serve pages with a high performance and high availability.
We currently have 3 EC2s installed. One is located on the West Coast of the United States, one is located in Dublin, Ireland and one is in Singapore. The main reason for that is that we’re deploying our product to a worldwide user base and we have to ensure a good user experience everywhere in the world.
Getting a caching strategy
A great caching strategy is also an important factor when it comes to performance. You can make use of various caching strategies. From short-term (seconds), to mid-term (minutes/hours), to long-term caching (like forever).
We are caching forever, which requires a good strategy to do so (in order to make sure that everyone gets the current data available).
We make use of a single-file hashing, set up with hashly. We added some custom scripts and modifications inside Hugo. Et Voila. So when someone visits usersnap.com only files which have been changed since their last visit, have to be checked and loaded.
Set yourself a deadline
I guess this is the biggest takeaway for us as a team and a product company. As a project-driven company or agency, you’re probably used to deadlines. They are everywhere. And they put you under pressure but give you a clear outline as well.
Being a product company we might not be used to such clear deadlines.
If a new feature isn’t ready to be shipped on the set deadline, it isn’t as bad as informing a customer that his website can’t go live.
But we knew that setting an internal deadline for shipping the new website is a key factor. So we did exactly that. And set a non-moveable deadline for our going live.
Every single tool we used for relaunching our website
Before ending this blog post, I’d like to give you a short overview of the tools used. I like being transparent and therefore I’ve collected all the tools and apps we’ve used to bring usersnap.com live.
- Idea generation: Paper, pen & whiteboards
- Mockups & Scribbles: moqups.com
- Content strategy: Google Docs & Spreadsheets
- Communication: Skype, Slack
- Design: Sketch
- Design feedback: InVisionApp
- Text Editor: Atom
- Web Hosting: AWS EC2, Cloudfront
- Frontend Framework: GoHugo, brunch, hashly, bash, bower, npm
- Development and Build Environment: Docker
- Analytics: Google Analytics
- Testing & QA: Usersnap
- Continuous integration: Codeship
- Other tools: hellobar, Google Tag Manager
- Lots of coffee
Wrapping it up.
All in all, it’s been a fun ride to bring usersnap.com live. Setting up a completely new web development workflow, making use of new technologies and redesigning the site requires quite a bit of resource, time and a lot of coffee 😉
This article was brought to you by Usersnap – a visual bug reporting software used by software companies like Facebook, and Microsoft.
Resolve issues faster with visual bug reporting.
Simplify and reduce issue & bug reporting efforts with screen recordings, screenshots, and annotations.
And if you’re ready to try out a visual bug tracking and feedback solution, Usersnap offers a free trial. Sign up today or book a demo with our feedback specialists.