Building Bloomberg New Energy Finance

  • Client: Bloomberg
  • Sector: Financial Services
  • Location: United Kingdom
  • Duration: 2014-15
You need to pick the right partner, and trust them.
Jon Moore, CEO, Bloomberg New Energy Finance

Bloomberg New Energy Finance (BNEF) is a division of Bloomberg, the global leader in financial software, data analysis, news, and video media. BNEF serves 2500 clients in 50 countries including the European Commission, BlackRock, HSBC, and the US Department of Energy.

The Brief

In September 2015, BNEF asked us to work with them to create new mobile offerings to bridge the existing gaps in the BNEF customer experience.

The need for mobile was felt internally and externally. BNEF have offered a successful web platform with an e-mail strategy since 2004 which needed to evolve to include a mobile offering. Rather than being desk-bound, their customers were reading email on the go while traveling or during downtime. Outside BNEF, mobile apps were becoming a staple for leading research companies and a differentiating factor compared to smaller businesses.

The timeline for the project was 3–4 months, so it was important to move quickly, whilst creating a high-quality solution inline with the BNEF brand. BNEF decided on a creative solution: partner with an experienced mobile product developer to build the first version of the app, while up-skilling the team and building an internal native mobile capability to own the next releases.

We wanted someone to push back on our ideas. We didn’t want someone to say ‘yes, we will do it your way.’ One of the impressive things about Future Workshops was that they had a way they wanted to run it. We feel we were in safe hands.
Albert Cheung, Head of Product Management BNEF

Below, we touch on particular examples that made this collaboration interesting:

Challenge: Defining a single value proposition in a sea of possibilities

The best apps are focused and deliver a clear value proposition to the end user. “It was essential that the firm we selected wasn’t merely focussed on the technical issues. They would need a bigger vision to take in the wider business context and a perceptive ability to ask probing questions,” says Jon Moore, “an app that doesn’t improve business on multiple levels is not a solution!”

How did we balance the needs of varied users who may be in different contexts? How can one app be tailored for someone catching up with news on the go and someone who needs to research a topic in depth without losing focus?

To get it right, we began with a Discovery phase. First, we analysed existing qualitative data about the daily routines of BNEF users and used this as a backdrop to workshop a potential v1.0 feature backlog. With a team comprised of technical, product design, customer service and delivery stakeholders, we prioritised these pain points to understand what the product should focus on first.

This gave us a clear lens through which to see the user value of the app. The key was to ensure any idea or feature that made its way into the app focused on a real, observable user need that can be addressed with tangible results for the business. These user needs and other artefacts from the Discovery phase remained with us throughout the project.

At this stage, the key was to create a narrow enough scope to allow us to prototype tangible solutions that we could test with users.

We produced multiple low and mid-fidelity interactive prototypes and tested those with the business team and end-users in London and New York. Starting with sketches pulled together into interactive prototypes in InVision, we quickly iterated on main app sections, making sure to get feedback from everyone involved on a daily basis.

Working in InVision meant we could test the main flows of the app with customers without writing any code. Participants could tap on the screen and interact with our designs and we learned from those interactions. We made quick iterations and our design team could put our next improvements into the hands of users right away.

The biggest benefit was avoiding the need to overhaul the code for the main structure of the app — thanks to this approach, we kept code iterations to tactical changes based on user and client input throughout the project.

Challenge: Content, content, content!

The relationship with BNEF’s content was bi-directional: it affected how we approached the app, and the app affected how content was written.

BNEF is the world leader when it comes to content on New Energy Finance. This means that our team had to quickly learn the ins and outs of the content and design a tailored experience.

Striking a balance. There were tangible risks and customer paint-points related to content. If users saw too much content that wasn’t relevant to them, they were less interested in accessing BNEF. John explained: “My nagging concern was to find the right mix of functions and content. The app needed to be both easy to use and precisely targeted to meet the critical business needs of executives. Senior-level users need to stay on top of all industry changes and also to dive deep into content whenever necessary. Striking that was critical.

”The solution was to allow a mix of ways to interact with content inside the app. We decided to prioritise individually-relevant content within a user’s pool of interests but allow users to explore the rest of the BNEF universe and discover more content if they chose to do so. The key was to avoid delivering too little, or too much.

Evolving content creation with mobile in mind. As a result of creating the mobile app, BNEF’s approach to content changed: research summaries became shorter and analyst reactions’ format changed to satisfy mobile users. It wasn’t just about changing the delivery mechanism of content, the new mobile app influenced how content was created inside the organisation.

One of the key learning points was the absolute need to cut through the chaff and give clients instant, any-time access to highly relevant content. We learnt to keep the message sharp, simple and clear… strip away everything that isn’t core and utterly relevant. That is the ‘Simplify and Improve’ mantra for successful app development and it quickly became the central discipline at BNEF.
Jon Moore, CEO, Bloomberg New Energy Finance

With a project of this scale, it’s common to encounter daily technical queries, product ideas, user feedback, or unanswered product questions multiple times a day. Addressing these promptly is key to delivering quickly and without surprises.We set up a few communication channels between the Future Workshops and BNEF teams:

Challenge: Building for the long-term

Developing in Swift. Launched by Apple in 2014, Swift is a significant improvement on Apple’s long-standing programming language Objective-C. Swift is a modern language that incorporates all the latest advances in language design, meaning it is vastly safer and more powerful than its predecessor. We agreed with BNEF that coding the iOS app in Swift would help future-proof the app and make the codebase as robust and maintainable as possible.

Swift training. To help the BNEF development team get up to speed, we created a tailored training programme focused on Swift 2, enabling them to work on the next release alongside Future Workshops lead developers. This was an exciting engagement for us, being among the first companies to offer professional training in Swift.

Creating maintainable code. We made the decision to code in Swift because it is inherently safer and more maintainable than Objective-C. There are stricter standards built into the language that encourage good software architecture, making it easier to pick up by other developers in the future. These stricter standards also reduce the kind of false assumptions that can lead to errors such as app crashes.

On Android, we tailored the app to the latest version of Android’s OS, Marshmallow. We built the code with modularity in mind when architecting the project. This means that, in the future, changing to a new technology related to networking or the database can be done with minimal impact. All the code is adaptive to the multiplicity of devices in the Android universe, removing the need to write specific code for phones and tablets.