FUTURELEARN: APP BETA RELEASE
NOVEMBER 2021
Course cover screen
Design, build and release a beta version of the FutureLearn learning experience to an invite-only audience of 200 testers.
01 / Summary
What was delivered and how?
Team
Design Lead
PM
Tech Architect
Tech Lead
4 x engineers
What I did
Define baseline styles and app design language
Design planning and strategy
Designed detailed user flows for key journeys
Wireframing
Prototyping
Mobile app design
iOS and Android design
Motion design
Handoff
QA
Deliverables
A fully-detailed journey map
Wireframes
User-interface designs for iOS and Android
High-fidelity prototypes
Animated icons (Lottie)
Impact
Over a 4-month period we took the app from seed idea to a basic learning experience that was released to an invite-only beta testing audience of 200 external testers. The beta app allowed us to quickly validate our hypotheis around how an app could complement the current web learning experience and potentially drive revenue for the business. It also demonstrated the capability of a newly formed team to deliver on the expectation to ship a full app within a year.
02 / Where do we start?
In February 2021 a new team was spun up at FutureLearn to build its first native app. At the time there was no prescriptive direction for the app and a somewhat ‘fluid’ business strategy, making this an added challenge. The app team was largely autonomous to define and set its own direction. The defining of a strategic direction for the app and its vision was parallelised and is detailed in this case study.
In the absence of a clear idea of what to build (yet) or where to start and a PM role yet to be filled (PM joined 3 months later), the tech lead and myself set about defining a starting point for the app. We decided that a safe assumption was that there would at least be a core learning experience of some kind in the app and that other parts of the overall FutureLearn platform could be deferred until later.
We worked to identify an MVP to give app users a coherent learning experience.
We settled on the following feature set:
Sign in / sign out
List of all courses a learner has joined
Show article and video content natively and defer all other content to a webview of the website
In-course navigation
Course progress indicator
Account page (terms and conditions, privacy policy, app version)
Tracking and crash analytics
03 / Illustrate Beta journeys
To test out this idea of a coherent journey I mapped out the overall app architecture, created detailed flows and navigation and brought this all together as a low fidelity clickable prototype. The team were able to get a feel for the experience, make suggestions and start to estimate how we would break down the build, look for complexity and estimate size and sequencing. We played back our goal and plans to the product leadership team and were given the go ahead to begin.
Journey mapping
04/ Design planning
While the engineering team were setting up their development environments and workflows, I set about laying the groundwork for the app’s design.
I started by considering my design approach. We had agreed to deliver both iOS and Android apps at the same time. Each platform has its own design language, style, UI and interaction patterns and users of each platform are familiar with the conventions that go with it. My initial position on this was that rather than going down a ‘branded’ route and keeping the design consistent between platforms we should follow iOS and Android guidelines, respecting those parts of the experience that we believe are conventions that we would not want to break. It’s a more time consuming approach, but I believe the reward of a familiar experience outweighs the effort.
We also needed to make a decision around designing for tablets and I recommended not to build specifically for tablet, but to use autosizing as the default and to make adjustments where necessary for example by constraining widths or changing layout from lists to grids.
05/ Baseline styles
FutureLearn already had a well-defined design system, distinctive brand and design language, but this had grown up and was designed for the web. One of my initial questions was how much and where would the app’s design language be consistent with the web and where would it meaningfully diverge.
I held a series of workshops with the design team (8 designers) to discuss and agree on a direction. The following decisions and work resulted:
FL’s palette lacks contrast. I refined the palette, while keeping the visual language alive, making it more complementary and efficient, especially with regard to introducing a dark mode theme.
FL for the web is flat. Because layering within apps is more common we need to be able to show depth. I introduced depth through transparency and blur and use of colour layering.
FL for web uses very little motion design or animation, but screen transitions and motion are integral to a native app experience. I defined some motion guidelines for timing, duration and motion curves and introduced Lottie animations.
FL’s font for web has a small x height and is not particularly readable on small screens. I switched the typeface to SF Pro for iOS and Roboto for Android.
06/ Design process
Without going into too much detail on any one feature set or part of the app in this case study, each piece of work followed a similar process:
Pre-planning and backlog refinement with the PM and Tech lead would enable me to pick up an epic and begin the design work.
I would start with problem definition, digging deep into the problem space to understand it. Desk research, competitor analysis, jobs to be done statements.
Design collaboration with other designers especially for opening up and finding alternate ideas.
Wireframing and prototyping.
Socialising designs and getting design critique - we have a weekly session in the design team to do this.
Refining designs.
Story writing with PM and Tech lead.
Preparation of design assets and deliverables.
Planning session with the app team to talk through the story and estimate.
In build I would often pair and do desk checks with engineers with build in progress.
Test and QA dev build.
[This case study for Learning Reminder Notifications gives a more detailed account of the design and build for a single feature.]
07/ Beta release
As we got closer to a final build for the beta app we:
Added tracking and crash analytics.
Onboarded testers to both iOS and Android platforms - internal and external releases.
Set up channels internally for feedback (Slack) and created a survey for external testers to be able to give feedback
07/ Outcomes
The Beta app was released in November 2021. Immediate reviews from testers were positive and we were able to see how the app could add significant value to the FutureLearn learning experience. Beta testers remarked on:
Much lower barriers to engagement, being able to jump right into their learning from their home screen.
A more frictionless learning experience with swipe gestures to navigate.
A simplified interface compared with the web experience, allowing them to focus on the content.
The addition of dark mode was very popular - some learners called this ‘focus-mode’.
The ability to do learning from anywhere.
Once the app vision had been created we were in a perfect position to start building out the full experience in the knowledge that we had established a solid foundation on which to grow.
