Concern Worldwide - Mobilisation & Usability

As the Internet matures and mobile technologies take center stage, a site that caters primarily for users on desktop devices simply doesn’t cut the mustard. Analysis of Concern’s website traffic clearly shows that a large and growing portion of users are attempting to access the site through a variety of devices, all with different shapes and sizes. What works well on a desktop doesn’t necessarily work so well on a device with a smaller screen size.

One of the main goals of the site is to facilitate donations, and conversion rates on mobile devices were low. Usability studies identified clear issues with the donation forms and the presentation of general information on the site for all users, but especially those on mobile devices.

“The number of visitors to our site has been rising steadily over the past few years. But we noticed a problem. There was a drop in traffic to our website from people using handheld devices such as mobile phones and tablets.” - Concern Worldwide

The key goals of this project were to provide an optimal website experience to users across a broad range of devices and to increase overall conversions. Whilst the previous website frontend focused purely on the desktop experience, the revised website would need to adapt and respond continually to its audience.

The process

Design and Specification

Initially, a usability study was conducted with Irish experts Each & Other. This uncovered major issues with the existing site’s user flow and enabled us to hone in on an optimal design that would benefit Concern.

Outputs from the design process included detailed wireframes that outlined intended functionality, user interface elements and behaviour expectations, as well as mockups and interactive prototypes that showed a general design, look, and feel.

The wireframe and mockups were then used to drive a series of discussions between Concern, Each & Other and SystemSeed, through which we further refined these ideas and helped break them down into a series of actionable user stories.

Scoping the Development Project

The SystemSeed development team then went through the stories again and again, piece by piece, breaking them apart until they felt comfortable that what they were looking at captured the full scope of the project. Each user story was given relative estimates of effort, as well as a score indicating a confidence level in those estimates. These points and scores were then extrapolated into a series of range estimates which enabled us to provide a good picture of the likely scope of the development project, with low-, middle-, and high-range estimates and an assumed likely case scenario.

The development process

After switching Concern to the Pantheon platform, we were able to leverage the benefits of best-practice Dev to Test to Live development workflows. The multidev feature enabled us to quickly and easily spin up new development environments for the development of individual features. At any one time, we had 10-15 different environments on the go, which enabled developers to work on new features for the new version of the site outside of other general changes being pushed to the supported live site.

Additionally we used a combination of Selenium Test Suites and Jenkins automation software to regression test the key areas of the site as we built out the revised version. This combination helped maintain all existing functionality and check for bugs automatically through the upgrade process.

An agile development process, with a fixed budget

At the start of the development project we had a huge backlog of user stories laid out in front of us. Some stories were small and we had estimates that we were confident in. Others were much larger and included things that the teams had less experience with.

Nobody can predict the future and we can’t know in advance what challenges a project may throw up at us, so an agile process where we would continually reevaluate our estimates based on increased knowledge and changing circumstances was imperative. What we would learn in two weeks' time or three months down the line could render the estimates from the start of the project obsolete. From a client's perspective, an agile approach where estimates will continually change can sound daunting, scary even. It can be hard to see how a fixed budget can apply to a project that is constantly changing in scope. In the end, it all comes down to a question of priorities. Throughout the project, it was imperative that priorities were continually reevaluated along with every other aspect of the project. The most important stuff stayed at the top, with less important stuff moving down to the bottom.

A fixed budget simply ends when it ends, and as long as the time has been used to best effect along the way, focusing on the highest priority items, the outcome should be one that everyone is happy with. Not all user stories from the original wish list made it into the final project, while others that hadn’t even been thought of on Day One did. Some stories are left unstarted, whilst others have been refined to the nth degree. There is certainly scope for a follow-up project in the future to revisit some of the original wish list items, but at the point where we made our final deployment, when the original budget ran out, the number of improvements that were delivered within that scope were evident in the final product.

Communication and shared understanding is key

As long-term strategic partners of Concern, we have a deep understanding of how to drive global collaboration and participation in cause-based activism. The alignment between the teams was key to achieving the goals of Concern stakeholders, and put SystemSeed in a trusted position to make recommendations or adjustments to enhance the success of the project and its outcomes.

We worked in two-week sprints. Each began with a Sprint Planning session between the scrum team and ended with a Sprint Review with the client and stakeholders, where completed work was demoed.

Throughout the process, we worked very closely with Concern. They had their own in-house project manager, and we have our scrum master and product owner. We would do regular backlog grooming in the scrum team, where we would discuss any obstacles, challenges, or recommendations for adjustments. This was a really key process and helped to ensure that everything was out in the open, priorities were appropriately adjusted and expectations were properly managed. The dev team had a daily scrum to ensure that everything was on track at every stage. Our scrum process helped keep all members of the team up to date on information exchange between the team and the client, while also allowing them to focus on each week’s sprint goals and user stories to complete without continual change from the stated desired work to be completed.

Our development team is spread around the globe and our client is in a different location yet again, yet through constant communication we were able to act effectively as a single team.

The results

After a lot of testing across a myriad of devices, the revised frontend was launched. Some of the highlights include:

The homepage

The homepage is a good example of the types of optimisations and adjustments that have been made throughout the site to cater for users on different types of devices. Essentially, the frontend is driven by the Omega 4 theme in conjunction with responsive Panels layouts. We work with five primary breakpoints and make different types of adjustments at each level. These range from minor style adjustments, to showing and hiding additional content, through to completely changing the layout and positioning of elements, which is done with the help of the Breakpoint Panels module. We use the Picture module extensively to provide fully responsive image handling throughout, ensuring that the most appropriately sized image is served for each device size. This helps reduce the bandwidth and keep the performance up. Google stated in a recent whitepaper that the short concentration span of a mobile user meant our pages had to load “immediately,” or we risked losing the traffic completely.

Improved donation forms

The donation forms went through a lot of usability testing. The number of fields was reduced to a minimal set and contextual help added where it was needed most. Clientside validation was added, and form error messages were moved inline to help people more easily identify and correct errors with their form submissions.

We also now pass details of any form validation errors through to Google Analytics using custom Analytics Events. This enables us to measure and take steps to further reduce the number of form validation errors our users encounter over time.

Extensive testing was done on mobile devices to ensure that all of the donation forms are quick and easy for people to use. We also added additional payment methods for both one-off and recurring donations (PayPal and Realex RealVault) to give users more choice in how they make their donations.

Registration process

Usability testing had highlighted clear issues with the registration process for the personal fundraising pages and so these processes were completely refactored. It began as a fairly complex four-page process, and was improved to become a simple one-page form. Users are now only required to provide absolute minimal information upfront, are automatically logged into their new user profile, and can then continue to build out their profile by easily uploading a profile image and setting their fundraising target.

We started with a system where each user could only have one fundraising page in a single currency, and moved to multiple fundraising pages, each with unique currencies. We started with a system that would send out generic welcome emails to all users regardless of the event they were registering for, and moved to a system where administrators have full control over every single communication that gets sent out.

The menu system

The menu system was refactored to include only those links of primary importance, presented in a beautiful and simple primary/secondary menu system. Users on mobile devices can experience a typical “hamburger” style representation of the menu which also incorporates the sitewide search facility for easy access.

Multiple releases across multiple sites

The release process was staggered, delivering value as soon as it was possible. That meant that we were running the new frontend on parts of the site, whilst the remainder of the site was still running the old frontend. We started by delivering iterative improvements to the most important parts of the site—the donation forms on concern.net—before moving onto other important areas of the websites that all run on the same platform, and gradually worked our way through the sites until all sites were complete and running the responsive frontend throughout.

This staggered approach helped to ensure that we could deliver value throughout the project and help concern see a return on their investment as soon as possible, rather than waiting for a “big launch” at the end of it all, as might be the case in more traditional development projects.