A detailed look at everything that went behind the redesign of the FusionCharts website - objectives, tech stack and server hardware, information architecture, front-end decisions to make it responsive, design tradeoffs, SEO, and analytics. The decisions we made, the process we followed, the learnings we had and the final results.

1. Redesigning a (fairly) large B2B website:
Behind the scenes of the new
FusionCharts website
The objectives, process, tools, tradeoffs, learnings and results
Compiled by @sanketnadhani with inputs from Prithwiraj Saha, Sumantra Sengupta, Uttam Thapa and @Godgeez

2. On Feb 1st, 2014 we launched the new
FusionCharts website

3. Old Website New Website
Launched on: 30th Dec 2011 Launched on: 1st Feb 2014

4. Why a new website?

5. Pain points with the old one
It looked old. Design, typography, language, the entire experience.
Got cluttered with all the additions made to it over time. A lot of repetitive
content, too many links, too many next steps.
Not optimized for mobile and tablets where we get 10% of our audience
from. 70-80% bounce rate.
Slow performance owing to legacy architecture (IIS6 where many
server-end optimizations did not work) and no focus on optimization right
from the start.
Not being able to maximize on SEO because of the website architecture
and performance.

6. Change of stack to LAMP from IIS. Reduced deployment time, ready
availability of modules and libraries (for performance optimization,
integration with other systems etc), bigger community and easier to find
people as well.
Bring in a CMS so marketing can change content directly. Yes, for this
large a website, we were without a CMS all these years.
Have the website focus only on our main product. Remove the links to
our other products that have their own websites and FusionCharts
extensions (for Flex, Dreamweaver etc) that we had stopped selling.
Measure everything that can be measured. Form conversions, PDF
downloads, which of the multiple download buttons in a page did the
user click on before downloading a trial.
Things we wanted to change internally

7. The entire process
Setting the
objectives
Information
Architecture
Tech stack
and hardware
requirements
Content plan
and complete
content for
one section
Content and
Design for
one section
Develop
main “shell”
of website
Remaining
content and
design
CMS
Integration
One section
live (get a feel
of it)
URL structureComplete
development
SEO
Analytics
Performance
optimization
Launch Fixes and
conversion
optimization
Make behind
the scenes
slideshow

8. Setting the objectives
Fresh modern feel across all devices and browsers (IE7 onwards).
Improve user experience and increase conversion rates as a result by 20%.
Blazing fast performance. PageSpeed score of 95.
Better SEO. Increase non-branded organic traffic by 30% over the 2013 average.
Measure everything that can be measured.
We shared the objectives with the entire team (the entire website was developed in-
house) and ensured everyone was on the same page. That way, every small decision
had to be made in line with the objectives.

9. Information Architecture - creating user journeys
Who are they? What do they do? What are their top concerns and motivations?
Why are they checking us out? What is the pain point they are trying to solve?
How did they come across us? What are we conveying in the first 15 seconds?
What stage of the buying cycle are they in?
Who else are they looking at?
What are the next steps we want them to take?
What do we want their complete experience across all touchpoints to be? This
includes date and time as well - people often forget things that happened on Friday
evenings and have to revisit it.
We wrote down user journey stories of different personas who come to our
website, and the experience we want to offer them.

10. John is VP Product Management of Aquasoft. They have 5 product lines with their
flagship product being an issue tracking application Lava which generates 65% of
the company revenue ($40 million). But right now their focus in on spreading the
revenue across different products so they are working on the new version of 2 new
but promising products - Influence, their collaboration product and TimeRack, their
time tracking application.
[Tuesday afternoon] Both Influence and TimeRack have their v2 coming up in 4
months. The requirements doc has been readied by the respective product
managers and been okayed by John. Engineering has started work on the building
blocks for the new features….[contd]”
User journeys - Example

11. [Tuesday evening] Both these products will have pretty extensive reporting
sections, more extensive than what they have in Lava (which could also use a
reporting upgrade in the next version). Given the new data-driven culture going on
within the organization, he wants to make sure the dashboards in his product are
also top-notch. The internal dashboards they have are basic but their external
products will need something much better and powerful.
John decides to look around for a charting component to see what's available in
the market to set the vision of what he wants his product dashboards to be like.
He can then pass on his pointers to the individual product managers and
engineering teams who can get the implementation done. He has some 25-odd
mins for this….[and so it went]
User journeys - Example [contd]

12. The single most important thing on the website. Affects everything else.
Principles
 Keep elements in the main navigation to a minimum to keep cognitive load to a
minimum. Also helps with better link dissipation from the homepage to only the
important pages for SEO.
 While keeping items to a minimum, also need to ensure returning users (40% of
our traffic is returning traffic) are able to find what they need quickly without
having to go a sectional landing page first. We decided to use a drop-down with
the least number of links possible for this reason.
 Do not try to be creative here. Keep the terminology as close to what users are
used to.
Information Architecture - Main navigation

13. Wrote down the different sections we envisaged on the website.
Mapped them against the persona(s) they are meant for, and whether its on their
first or return visit.
Identified the sections that might be removed or different on different devices (for
example - trial download doesn’t make sense on a phone or a tablet).
Ran the sections through the user journeys created in the earlier step.
Iterated till the navigation was the best fit for the user journey stories we had written.
Iterated some more.
Finalized.
Main navigation - how we went about it

14. Main navigation - how we went about it

15. We are visual people, so we got a complete design of the main navigation bar done in
Photoshop, both for desktop and mobile.
Main navigation - design
Desktop Mobile

16. Did some more iterations after we got a “feel” of it.
We also decided to make the navigation sticky since a lot of our pages are long and we
want the navigation bar to be easily accessible whenever users want to jump to a
different section (rather than having to jump to the top or be presented with a whole
bunch of links again in the footer in a different style)
Main navigation - design

17. Tech stack and hardware requirements
Website performance depends on a bunch of factors:
 Server hardware
 Server OS and software installed
 Web application performance on server-side
 Client-end performance
 Network Latency
 Load balancing/distribution
 …and more
We had already decided to move to the LAMP stack from IIS.
To get blazing fast performance, now we had to get the best server hardware.

18. Server hardware
Got historical data on peak usage pattern from Google Analytics - max concurrent
users and max load
Wanted to optimize for a 3x increase in peak usage without putting too much stress
on the server to keep enough room for growth (growth-hacking B2C companies, 3x
might not be a lot for you, but for an enterprise software company, that’s enough
room for growth :) )

19. Server hardware - Load Testing
Different stacks and technologies have different hardware footprint due to their design,
so load testing was needed to determine the server resources required for the given
traffic and configuration. Ideally server load should never shoot up more than 20-25%
Used apache jMeter and apache benchmark for load testing and New Relic for server
monitoring
After the exercise, we decided to have 16 Gigs of RAM, Quad core CPU and 15K RPM
Drive

20. For all the pages in the new website, we identified the content required in a
spreadsheet along with how to get it:
 Port directly from an existing page
 Modify from an existing page
 Write from scratch
A lot of companies create an inventory of the content they currently have - we
purposely avoided that because we wanted to throw away as much of the content
as we could and keep only the important stuff. Doing it this way helped us be
heartless.
Content plan

21. Wrote complete content for the product section. It was a good section to start with
because it sets the tone for all the other sections and involves a lot of different
design elements.
Got the design done for the complete section with the content and images.
Collected internal feedback on the design.
Content and design for one section

22. Finally got all the other elements needed in. Breadcrumbs, header, next steps,
footer and side panels. Again being visual people, we like to get a “feel” of these in
a final design rather than a sketch, wireframe or list of elements to be added.
Content and design for one section

23. We decided to create a responsive website instead of serving separate HTML based
on user-agent or separate mobile and desktop URLs:
 Have the same experience across all devices (even the ones yet to come)
 Easier to manage
 More efficient crawling by search engines
 No redirections needed based on user agent (which is error-prone)
Develop main “shell” of the website - Decision
on why build a responsive website?

24. We decided to use a 12-column grid system
 It supports 5 different kind of column layouts (1 column, 2 columns, 3
columns, 4 columns and 6 columns)
 While a 24-column layout also supports all the layouts, it would need some
more CSS to be written
 All popular frameworks use the 12-column grid system
Develop main “shell” of the website - Choosing
the grid system

25. Decided to build a custom CSS framework instead of using Bootstrap to keep it
lightweight and have a cleaner stylesheet.
Used LESS as CSS preprocessor. Easy learning curve, no dependency on
environments or tools (JS-based compiler and awesome free editor called Crunch)
Develop main “shell” of the website - Building
the CSS framework

26. Used jQuery for front-end user interaction like form validation, animations and tabs.
Used hcsticky.js for sticky navigation, fancybox.js for lightbox, Prettify.js to beautify
the JSON/XML data in our demos and Bxslider.js for sliders.
Develop main “shell” of the website - Other
libraries we used

27. Used the Google Font Library - Paired Aller (serif) for all the headings with Open
Sans (sans serif) for body content
Zipped the fonts and cached them to ensure the best performance
Develop main “shell” of the website -
Typography

28. Wrote content for the remaining sections of the website just like the first one.
Writing content for forms is something that can be easily neglected during the
content writing process. But being one of the most important elements on the
website, we wrote all the headings, labels, privacy policy messages, content for
the form completion messages during this process.
Remaining content and design - Writing content
for forms

29. We needed a CMS so that marketing could add or edit content without involving
the web team at all. But we wanted something that didn’t come in the way or
changed the way we build websites.
Perch, a lightweight PHP CMS, fitted in perfectly. We just had to add Perch tags to
the parts of the website we wanted to make editable and that’s it.
Even the interface for adding and editing content was very simple, making the
choice a no-brainer.
CMS Integration

30. Keep them short and user-friendly. Doesn’t have to follow the exact site structure -
eliminate the directories from the URL wherever it makes sense. Example - even
though our tour is under the product section, we kept its URL as
www.fusioncharts.com/tour.
While short, they should be descriptive enough so that when people come across
the URL in search, other blogs/forums or on social media, they get an idea of what
the page is about from the URL itself.
URL structure - principles

31. URL structure

32. We had thrown out a lot of the content, so a lot of high traffic pages had to be
redirected to the most relevant page.
We got a complete list of all the pages on the current website.
Wrote redirections for each page manually to send traffic to the best possible page
in the new website.
URL Structure - Redirecting old pages

33. Keyword research
 Started with the basic set of keywords that we already optimize for search
and identified more variants using the Google Adwords Keyword Tool and
Wordtracker. In this phase, just focused on finding more keywords not on
what keyword belongs to which page etc.
 Noted down with their monthly search volumes, difficulty of ranking for them
and a summary of what the other search results that come up for the term
(helps identify if that is a keyword you should be targeting at all)
Grouped related keywords and added up their volumes.
SEO - Keyword Research

34. Finally mapped individual pages to keywords based on the search volume and the
realistic chance of being able to rank for them.
 Identified 1-2 primary keywords for every page and 4-5 secondary keywords
 “Money” keywords go to “money” pages, “educational” keywords to “educational”
content
 For some inner pages, had to do keyword research again.
 The entire process also helped us come up with content ideas that we hadn’t
thought of before.
 There were also pages that had no keywords to be optimized for (our Product Tour
section). That’s alright.
SEO - Mapping keywords to pages

35. Based on the primary keyword for a page, we wrote the meta title and description for
the page - central ideas we followed:
 Possible formats were Page Title | Brand Name or Brand Name - Page Title.
Ideally the closer the keyword to the beginning of the title, the better the chances
of getting a higher rank in Google but if you have a strong brand name keep the
brand name at the beginning to differentiate yourself in the search results. For
example, for our homepage we use: FusionCharts - JavaScript Charts for the
Grown-Ups even though we want to rank for “javascript charts”
 Meta description doesn’t matter for search engines but think of them as an ad for
your page - lure people into checking out your page through it. Add a call to
action in the end to nudge them.
 The title and the meta description of the page get shared on social media if you
don’t have meta data defined, so write them in such a way that they make sense
when shared on social media as well.
SEO - Meta titles and description

36. Inject keywords and their variants in the content if applicable to make the content
keyword-rich.
The idea behind doing this at a later stage is to ensure the content is written first for the
readers, and then for the search engine (if at all possible without affecting the flow).
SEO - Make content keyword-rich

37. Got Google Analytics (GA) installed on every single page we wanted to track. In our
case, that was every single page.
Got events for everything that cannot be measured as pageviews in Analytics. PDF
downloads, zip downloads, form completions, video views, external links and more. We
even used it to optimize for better conversions with all forms. Principles we followed:
 Architect the events from what you want the end report to look like. Spend some
thought on how extensible they are to accommodate your future plans.
 Do not pay much attention to the Action and Label tag events in GA have. Use
them the way you deem fit depending on how the end report looks like.
 The same action can result in multiple events as well. For example, a trial
download goes under our Download Trial category as well as Conversion Rates
category where we track how many people got to the form, how many got an
error and how many people actually completed it.
 Ensure they are implemented the correct way. Making decisions based on wrong
data can be very, very dangerous.
Analytics

38. Aim was to get get PageSpeed to 95+
Followed best practices from Google's PageSpeed Insights Rules and Yahoo's
Exceptional Performance team. Minimizing HTTP requests, minifying resources,
prioritizing the visible content, using asynchronous scripts etc. Principles followed at:
 PageSpeed Insights Rules -
https://developers.google.com/speed/docs/insights/rules
 Best Practices for Speeding Up Your Web Site -
http://developer.yahoo.com/performance/rules.html
 Google Ventures - Startup Lab workshop: Web front-end latency -
https://www.youtube.com/watch?v=ch68MXWUfjo
Performance optimization

39. Performance Optimization
Optimizing client-side resources required optimization of each and every single
resource.
But were behind schedule, so decided to do it centrally using mod_pagespeed
module from Google which optimizes assets on runtime. Needs semantically correct
HTML.
Also wanted to implement varnish cache but had issues with configuration, so kept
on hold. But once implemented, it will give us performance improvement of 60% over
previous website.

40. Performance Optimization - Application Profiling
and optimizing
New Relic was our one-stop tool to profile server, application and client-end
performance which we made use of heavily to iron out all chinks.
For example, we found out that SalesForce API calls from our sales forms were
taking a long time impacting user experience. We could not figure out how to improve
it, so we created an intermediate database where the data got stored and made API
calls using scheduled scripts, thus ensuring the user did not have to suffer at all.

41. Planned launch date 3 weeks in advance - kept it on a day when traffic is the
least.
Conveyed launch date to the complete team and to our partners. Set the right
expectations with the team, especially sales. Things break with a new website,
search engines take time to reindex it, so they needed to know that numbers will
be down for some time.
Made conversion rate the top metric to look at. Even if traffic went down for some
time, conversion rates would help us understand if the overall experience of the
website was better.
Ensured everyone involved with the website was only a call away for at least a
week after launch.
Reiterated what success for the new website looked like. Also put together a plan
B if everything went wrong.
Getting ready for launch

42. …and we launched

43. Changed goals in Google Analytics and put the main metrics on a dashboard and
shared with all key people.
Tested the live website:
 Homepage
 Trial downloads
 Sales and tech support forms
 Demos
 Static content
Post-Launch – Fixes and conversion
optimization

44. Told the entire team about the new website. Created a spreadsheet where they
could add in all issues and bugs they found. Avoided email or in person reports as
there are 500 things that will break and info will be scattered all over.
Kept prioritizing the list as urgent, high priority, medium and to be fixed later.
Got a list of pages throwing 404 daily from Google Webmasters and mapped them
to the correct pages. Did this for a week till the numbers were within acceptable
levels.
Kept a close eye on the dashboard.
Post-launch - Fixes

45. Kept asking for feedback on the new website proactively from the team, customers
and partners. Forced them to be brutal. The more brutal the feedback, the more
the room for improvement.
Kept experimenting to optimize conversions. The events set up earlier were great
help here. For every experiment, we put together a hypotheses, launched it, kept a
close eye on the numbers and determined whether it was successful or not when
we had sufficient data points.
Till 2-3 weeks after launch

46. Results - how did we do with our objectives?
Fresh modern feel across all devices and browsers (excluding IE6).
Improve user experience and increase conversion rates as a result by 20%.
Blazing fast performance. PageSpeed score of 95.
Better SEO. Increase non-branded organic traffic by 30% over the 2013 average.
Measure everything that can be measured.
Let’s look at them one-by-one.

47. Fresh modern feel across all devices and browsers.
It’s a little subjective to decide how people like the feel, but here’s what people think:
Marginal improvement of 3% in bounce rate on mobiles and tablets. Largely due to
issues we had with navigation on touchscreens which we have fixed. We will continue
working on the experience on mobiles and tablets
Results - how did we do with our objectives?
FusionCharts’ new website, loved the UI
Phoenix Chang, Juntiansoft Technology
The revamped website looks awesome
and we loved the spanking new
dashboards
Johnson Chang – Frog – Jump
Information

48. Results - how did we do with our objectives?
Improve user experience and increase conversion rates as a result by 20%.
Surpassed it. 24.4% increase in goal conversions.

49. Results - how did we do with our objectives?
Blazing fast performance. PageSpeed score of 95.
PageSpeed score - 96.
Page Load Time - improved by 20%.

50. Results - how did we do with our objectives?
Better SEO. Increase non-branded organic traffic by 30% over the 2013 average.
We have seen a 14% increase in non-branded organic traffic in the month after the website
release, but we are still far away from our goal. We have to keep working to get to the goal.

51. Results - how did we do with our objectives?
Measure everything that can be measured.
We have beautiful data coming in which we use for optimizing conversions at key
touchpoints - largely as a result of which we have been able to improve conversion rate
by 24.4%.

52. Testing. Could have done in it a much more systematic manner before the launch
release so we wouldn’t have had to spend a month after the launch juggling
between fixing things, running experiments and working on the feedback we got.
Menus were problematic on tablets, performance issues on Safari etc.
Too much inspiration from different companies we admire in the middle of the
process and too many changes as a result.
Being too optimistic about SEO. It takes time with a new website.
What could we have done better?

53. What do you like about our new website? What could have been
better? Check it out at www.fusioncharts.com and let us know in
the comments below.