The launch of this site marks the completion of my second community platform design/build/migration project and I’ve learned a lot from both. Here are some of the lessons I’ve learned, along with some useful resources.
Building something like this takes time and money.
Bespoke software is expensive. It’s also not the best approach for a community platform in my opinion. Too much time is spent reinventing the wheel. What we decided to do when we planned this site, was take two established but flexible platforms (WordPress and Discourse) and integrate them to create something new and appropriate to our audience.
I began this project when I started with FeverBee in January. The rest of the team already had an idea of what they wanted to achieve and had put together the bones of a functional spec.
I began the conversation with our development team on January 20th 2015. We soft launched on July 13th.
It took 6 months from start to launch.
It cost US$20k for the platform customisation.
On top of that there are some extra costs:
$2k for a Discourse consultant (our dev team had no Discourse experience)
$120 for a WordPress template (we are using Eptima by Sketchthemes)
$264 for a font (we are currently using Rehn Condensed)
$450 for a designer (to design our homepage)
$60 for an EU cookie compliance law solution (we use Cookie Control by CivicUK)
A very important thing to note:
I managed this project and wrote the inner pages (i.e the pages which aren’t the homepage). If you don’t have someone on your team with the experience to do both these things, you can probably add another $10k onto the bill.
Discourse has been around for a couple of years now but it has really only recently started to become mainstream. It is open source so theoretically you can do anything you want with it, but in reality there are limitations. Firstly, unless you self-host (which I wouldn’t recommend unless you have a dev team that are comfortable working with Rails), you are limited to what you can change through the admin panel.
Secondly, Discourse is very much a work in progress and as such is frequently changing. In my previous job we made the mistake of very heavily customising it, to the point that we hamstrung ourselves and couldn’t update without having to rework a whole lot of things.
Don’t let this put you off though. Start simple, and then if necessary, commission plugins. Discourse has a marketplace where you can find developers to work with, although at the moment the demand well outstrips availability.
And for WordPress (aside from a number of standard SEO and comment validation plugins):
WooCommerce (for selling resources)
Mailchimp for WordPress Pro (sends new signups to our mail list)
Discourse for WordPress (ports article comments to Discourse)
Username changer (by default you can’t change your WP username)
Paid Memberships Pro (for subscriptions)
Shareaholic (for social sharing)
Primetime WP Discourse SSO (for single sign on across platforms)
Stripe for WooCommerce
WordPress Social Logins (for login in via social media)
If you decide to use WordPress, you can choose to base it on a theme or a theme framework. Your developer will advise you. Frameworks are more flexible but require more work and therefore the site will cost more to develop. Themes allow you to choose an aesthetic that suits your brand, and come with built in modules that offer different functionality. They also mean that the non tech-savvy people in your team can control the site using the UI.
Free themes are available, but not recommended. If you want something secure and robust with good support, you’ll need to pay. A good theme will cost somewhere between $50 - $200.
The biggest theme marketplace out there is Envato’s Theme Forrest, but beware of their exorbitantly priced extended licenses (which you’ll require if any part of your site is behind a paywall).
Important note: Any theme can be customised so focus on the overall look and feel (does it reflect the professional/fun/slick nature of your brand?) rather than the granular details. As mentioned previously, this site is based on Eptima by Sketchthemes.
When migrating data from Braintree (or any other payment platform) to Stripe, subscription data isn’t transferred, so you’ll need to manually recreate any subscriptions. Unfortunately that process tripped fraud triggers with a number of credit card providers, and the payments were blocked.
When new members register with us, their details are automatically sent to a list in Mailchimp. That kicks off an automated series of on-boarding emails. We think this is crucial and recommend it for any new platform.
Working with designer
One of the first steps in a project like this is coming up with a design. We worked with Joel Carlo to design our homepage, the rest we did ourselves. Try to avoid designing by committee – it drags out the process and can result in everyone feeling disappointed. Make sure you have a clearly documented concept (and ideally wireframes) when you go to the development team.
Working with a developer
We used Grazziti, who are based in India, to do the bulk of the development. They are great to work with and very reasonably priced. We negotiated a fixed price for the project which included project management on their end. We would definitely recommend Grazziti, but note that although their technical work is top notch, they are not very strong on design, so make sure you have that side covered.
Where community and UX collide
There are almost always aspects of a UX project that have to be compromised. A UX designer’s primary goal is to minimise the cognitive load required when consuming a web experience. Two of the key ways to achieve this are to provide short-term memory support (achieved by visually displaying things that would otherwise have to be remembered eg: change the colour of links once visited) and using recognition over recall (eg: using internationally recognised icons or unambiguous CTAs).
I came to this project from a UX angle, Rich from a social psych/marketing one. We both had to compromise our ideals on a few things.
The Ask FeverBee button
Good UX practice dictates that button labels describe what will happen when you click them. For that reason I proposed that the homepage CTA was labelled Start Discussion. Rich suggested Share Tip or Get Help because he wants to nudge and train people when to use the site (ie he wants the discussions to be practical and focussed). We settled on Ask FeverBee but that will likely change. We’ll test a few options.
Our vision for this site is to have crowdsourced content blended with our own content on the home page – a one-stop community shop. Part of our strategy to encourage people to post great content on the forums is to display their avatar on the home page when they contribute, in essence strengthening their personal brand. I love the idea, but without visual cues, people have no idea where the content is coming from. My initial design included gridlines between rows which would carry source indicators (New from FeverBee, Latest from the Community, More from FeverBee etc). We ended up doing away with those so that we could maximise the content displaying above the fold.
We compromised by using round avatars from Discourse on the community posts, and square ones on the blog posts. It is still not best UX practice by a long shot, but I can live with it.
Launch with something and then refine it.
It’s very easy to make assumptions about the way people will use a platform, either because that’s how you’d use it, or because that’s how you hope they will. It’s important not to get too bogged down in the minutiae at this point. It makes more sense to launch with something functional and then tweak things that aren’t working.
Use a tool like Optimizely to test different options. Make sure that you launch with analytics or you won’t have a clear picture of what those things are.
My No 1 tip for new players: Test early and often
If you’ve never developed software before, you probably have no concept of how much time goes into testing. Testing is not a one person job. People follow processes differently and have different requirements, so it’s easy for one person to miss something that might be important to another. It is also crucial to encourage all stakeholders to start testing processes as soon as they are stable, so that there are no surprises down the track when it’s too late to change things easily.
And lastly, test often. Changing one thing can have knock on effects across your site, so something that was working yesterday may get broken by seemingly unrelated changes made today.
If anyone is embarking on a project this large and wants support, get in touch, we can help.