Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Redesigning a large B2B website - The FusionCharts revamping story


Published on

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.

Published in: Technology
  • Be the first to comment

Redesigning a large B2B website - The FusionCharts revamping story

  1. 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. 2. On Feb 1st, 2014 we launched the new FusionCharts website
  3. 3. Old Website New Website Launched on: 30th Dec 2011 Launched on: 1st Feb 2014
  4. 4. Why a new website?
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 14. Main navigation - how we went about it
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 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. 31. URL structure
  32. 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. 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. 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. 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. 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. 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. 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 -  Best Practices for Speeding Up Your Web Site -  Google Ventures - Startup Lab workshop: Web front-end latency - Performance optimization
  39. 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. 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. 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. 42. …and we launched
  43. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 53. What do you like about our new website? What could have been better? Check it out at and let us know in the comments below.