I wanted to create an online macro-economic data platform that allowed a business to better understand the impacts of Brexit and navigate a path through all the conflicting surveys, economic and financial data, as well as confusing and often one-sided media comment. And I wanted to do this online and digitally.
I’m not a digital design expert, nor a data scientist, but on a relatively small budget I’ve managed to build a unique digital service called The Brexit Tracker. It has opened up offers from partner firms who aren’t nimble enough to build their own platform – or perhaps didn’t want to fail in their attempt.
Here are my 10 main observations when building your own online service or platform using the power of digital technologies – to solve your own business’ problems without breaking the bank.
1. Undertake market research: end user opinion is vital
This market research was costly and slow to gather, but exceptionally useful. It redefined our target audience (SMEs simply weren’t interested in Brexit, mid-sized corporates were and said they needed help.) Understanding our audience meant we changed the design from an app to an interactive web platform.
2. Build yourself a prototype: early problem identification
An Excel based prototype allowed us take a sample of economic data and produce meaningful results. It told us what user information was needed – and what wasn’t.
Our aim was that anyone with knowledge of their business could use the Tracker, so only general, easy-to-know business questions were allowed. Our challenge was to design the process that provided a user with unique Brexit insight.
3. Testing of the prototype: by end users
End users told us the prototype was complicated to follow and parts weren’t logical. Ouch.
With hindsight we should have spent more time on the prototype’s user interface and engagement and then re-tested. I didn’t truly incorporate what my early testers were telling me, choosing to believe that when they saw it online, all their questions would be answered. This ended up with lot of painful redesign at a time when we could have been engaged elsewhere.
Top Tip 1: Allocate time to adjust your prototype on user feedback. Don’t rush to the design phase, as you’ll regret it in costly revisions.
4. Selection of your design/coding firms
How much effort have they made? We asked three firms to follow a brand and design brief, providing them with the prototype. We invited them to provide their own brand ideas. Here are my considerations for selection:
- Cost – I was self-funding this, so I set budget expectations from the outset.
- Coding skills – Big data expertise would be crucial. If they didn’t ask questions on the prototype, this suggested they hadn’t understood it, or even worse, they hadn’t looked at it. A big no no.
- UK based – I knew I’d be running multiple amendments and revisions, so working to UK hours was crucial.
- Fixed (rather than variable) price contract – this was dictated by my [lack of] budget. It would mean that if I asked for too many revisions, I’d run the risk of the design/coding agency losing enthusiasm. This was partially solved by maintaining an effective relationship and being ultra-clear on the revisions.
Top Tip 2: All under one roof – I’ve run projects using multiple agencies; a design firm for the visuals and web layout, a firm for the website front end and another for the back end. I had to work very hard to keep everyone communicating with each other, where failure caused unnecessary delays. This was a headache I wanted to avoid.
Final selection: I knew the Brexit Tracker was going to stretch my own resources, so I was clear I needed a single agency, that could deliver across all silos. Ben Harper at Clarity Stack couldn’t have been a better partner and it is fair to say we got to know each other well. We designed the front end and back end at the same time, which saved time, but needed to be run intelligently, so one decision didn’t impact another down the line. This was achieved by having everybody under one roof, communicating with each other; and crucially, being paid under one agreed budget.
5. API or manual data updates? Start easy, then complicate
The Tracker’s success would be a function of how closely we could recreate a user firm’s unique business operations – using as much official data and surveys as a user could handle. The prototype took feeds from only 40 macro-economic indicators. The current version takes over 1,050 monthly indicators and the list is growing.
I looked at building APIs from the providers of this data – but quickly found that the underlying format could change each month and each source of data needed manipulation before being uploaded into the Tracker. An Excel based, manual data upload solution provided the easiest, cheapest and quickest way. API was pushed to future upgrades. This was one of my better decisions.
6. Future proofing: think ahead
I wanted to ensure that I had an unlimited ability to add new economic indicators and include or change industry sector categories and profiles. I didn’t want to use a ‘change request’ process, reliant on a third party. So we designed an admin panel into the back end.
Looking back I should have spent more time on the admin panel design in the prototype days. I needed to consider how I was going to manage, sort, reference and upload all data and supervise user profiles. The resulting processes are largely manual at present, requiring duplicated effort, and extra processing time. The things you learn the hard way…..
7. The user journey: our key focus
We needed to simplify. To create a clear, easy-to-follow user journey, where users educated themselves on the art of the possible. We used icons rather than words, and consistent colour coding throughout. We divided the user on-boarding into five logical steps, allowing users to jump backwards and amend answers, with auto save. This became an art rather than a science.
8. The user interface: instant gratification
Ten to 15 minutes in user on-boarding would require significant user buy in. Maybe too much. So we re-arranged the five step process, providing analysis and feedback on a user’s Brexit views in Step 2, reached within 30 seconds. If they liked what they saw, they’d continue to invest their time into the platform.
9. User profiling: keep it simple – make it quick
There are 25,000 different user permutations, allowing the Tracker to be accurate to every firm. Relying on the user ‘self-educating’ principle, we pre-populated the selections a user could make, while informing them they could change the selection at any time. This vastly reduced the time taken, allowing them to click through, view their results dashboard, then make amendments (to our pre-populated answers.) This was a giant leap forwards.
10. Testing, testing, and testing: plan to do a lot
As the both the front and back ends were being built, we could test the coding that would ultimately drive 6.5 million calculations. Another benefit of an established prototype was that we could use it to run tests.
Despite its simple tech, the prototype was hugely efficient at demonstrating how the coding should work. Some coding fixes required redesign of the user engagement process, so we should have invested yet more time into the planning stages. Yet, sometimes one has to develop, release, assess and then modify as you are running. Accepting and incorporating these agile work routines, across the entire team’s output is vital. And your budget and timeframe must incorporate this, otherwise everyone’s interests are misaligned.
The overall result
I’m very happy with what we accomplished, within budget and only two months over a nine month original timeframe. Partners have complimented us on the user flow and storytelling element – and consequently we’ve been asked to design platforms for them.
The Brexit Tracker is proof you don’t need to spend hundreds of thousands pounds to create your own online, digital platform, or for it to take years in the making. What you need is some creative thinking, time commitment and above all someone in charge, fully accountable at every stage. Then anything is possible.
My main lesson: Next time I’ll spend even more time on the prototype and assess every possible journey – both from the user perspective and my own.
Further reading:
Econsultancy training:
Comments