React GraphQL Academy 2018 site - design case study

Our React GraphQL Academy is one of our proudest achievements here at LeanJS. There really isn’t anything quite like seeing students learning a new skill that could potentially change their lives, but that’s the big picture. The individual moments of things clicking into place within our alumni’s fertile minds, and working closely (literally) with them to achieve it — you really can’t beat it!

The courses React GraphQL Academy offers have been perfected over time, in the iterative, test-driven way that we do things here and as such, the curriculum is the most complete on the market. However, our website was not as refined and was proving to present many problems to us, and to users.

So it was time for a change! New ideas! A new website from scratch!

Complete project timeframe overview — 3 weeks

• Stakeholder discovery: 0.5 day
• User research & recruitment: 3 days
• Data analysis and ideation: 1 day
• Wireframing: 1 day
• Coding prototype: 6 days (check out Alex’s blog)
• User testing (2 rounds): 2 days
• Prototype iteration based on user feedback: 3 days
• UI design/coding implementation: 3 days
• Setting up quantitive benchmarks: 0.5 day

As you can see, our design and development timeframe was very short (3.5 weeks from research to design to development and launch), but we intend to share everything with you! Therefore, these blogs will be detailed — this one will cover the design side, and our development lead Alex will cover the geektastic/magic tech side of things in a separate post. Let’s get into it…

The UX Process

Before getting involved, I’d like to quickly detail my general process… Here’s what I did:

• Gather user stories from stakeholders
• Interview primary stakeholders
• Create problem statement
• User interviews
• Create jobs-to-be-done
• Our take on the Value Proposition Canvas
• Wireframes
• Testing round 1
• Iterate on design
• User interface design (launch)
• Testing round 2
• Iterate on design

Enough of the lists, here’s the detail…

Discovery — stakeholders

Time taken: 0.5 day

User stories

As with all projects, it was essential that I understood the key business needs and risks associated to redesigning Reactjs.academy.

Taking the time to speak with Alex, Richard and Horacio— the brains behind the course and serial beach-frollickers (see below) — was essential but before I spoke to them, I asked them to create as many user stories as possible.

If you’re not familiar with user stories, they’re like use cases with the ‘why’ added. Here’s an example

As a developer, I want to see who has done a RJSA course and what they think so I can see what the hype is about.

…here’s another…

As a manager, I want my developers to learn React quickly because we have a deadline to finish a project built using this new tech called React and we have a huge delay

In addition to Alex, Rich and Horacio, I asked React GraphQL Academy coaches and our customer service team to create them too. Afterall, who speaks to the users (students) most? Customer service and our coaches!

Gathering them all together gave me an idea of what stakeholders assumed were the big problems to solve from a user perspective. Although that sounds like a lot of work for them to do for me to ‘get an idea’, don’t worry — I’ll be using them later in the process to help create a backlog moving forward.

Stakeholder interviews

With a rough idea of the assumptions that were floating around, it was time to actually speak to people. Gleefully, I was happy to be able to test using my take on a business model / lean UX canvas — my ‘assumptions canvas’.

Thing is, when you’re working as quickly as we do at LeanJS, you need to find (or create) the most efficient way of getting what you need. I wanted to create a tool that is helpful to me moving forward, document the key points that are needed to justify decisions going forward but also make it flexible enough to employ in a workshop environment as well as when I’m conducting user interviews.

Here’s what I created, the Assumptions Canvas:

The idea is to get all the assumptions of the stakeholders down onto one sheet of paper (or image) and foster alignment in the business. Not only that, it’s getting them to think of their users’ as people and not business opportunities.

Saying that, as you can see, it’s not all users-users-users! On the right hand side is key business information I need to ensure that I’m meeting the client’s business needs and goals, considering their risks and designing with their USPs and competitors in mind.

In this instance, it was very busy times at LeanJS (the React GraphQL Academy Lisbon bootcamp was the week after!) so getting the key stakeholders into the same space wasn’t possible. This meant that I had to fill in this canvas during stakeholder interviews, which worked well enough to move onto the next stage…

User research

Time taken: 3 days

User interviews

As you can see on the canvas, I asked about the assumed users for the React GraphQL Academy site — also the user stories garnered a bunch of demographic ‘user types’ to work from..

It’s work noting that although UXers don’t subscribe to using people’s demographic information to design from (it’s all about behaviours, needs and pains baby), most stakeholders will give you a bunch of job descriptions in the ‘Users’ section. At this stage, this is perfect because, well, user recruitment.

For the React GraphQL Academy website, the general target users were:

• Working developers who want to learn React to improve their career
• Tech leads (^ their bosses) who send developers to training
• HR people who hold the budgets for training

After recruiting users, I had 20–30min conversations that covered many subjects around training, development and buying online. Although having a plan of questions you’re going to ask is key to ensure you stay on track, delving deep into painpoints, motivations and behaviours is essential so you can design for the deeper needs. That generally means your plan works more as a ‘conversation guide’. Anyway, here’s the questions I tried to cover:

• Do you know/use React?
• Do you have any future plans to learn/implement it?
• Why do you want to learn React?
• How would you approach learning a coding language/framework?
• Have you considered signing up to an offline course?
• What worries would you have with doing so?
• What would you value most when considering buying a course?
• How would you look for such courses?
• Who would pay for your course?
• Would you try to get work to pay? How would that work?
• What are your experiences when buying tickets online to attend events?
• What really annoys you when you try to do that?

…each question followed by “why?” which is said in a myriad of different ways so I don’t sound like a petulantly annoying child who can’t get the answer they want from the question “Can i have a biscuit?”. But I digress.

Key findings — the jobs-to-be-done

So now we can go back to our ‘Assumptions Canvas’ and evolve it into the ‘Validation Canvas’. To do this, we cross out what we’ve found was incorrect assumptions, leave the validated assumptions as they are as well as add any new findings in red.

Here’s what it looked like:

OK, so you can see that there’s information about the users on the left which can be used in a couple of different ways. You could use UX personas but, they can be restrictive so we use jobs-to-be-done (JTBD). If you’re wondering, our reasoning behind using JTBD is on our blog “Open source brand — LeanJS, ‘Iteration’ 2… Research”.

Synthesising the above information into JTBD that fulfils the business and users needs is part-and-parcel of a UX designer’s job — it’s tricky, but also very rewarding (especially when it pays off later on down the road). Anyway, here’s the primary JTBD for the React GraphQL Academy website:

JTBD 1: When looking for ReactJS course, I want to visit the site and understand whether the course is at a certain level, so I can feel confident that I wont waste time/money applying for the course.

JTBD 2: When I’m looking for a training supplier, I want to find information about the company and the training staff, so I know that they’re a viable, trustworthy company worth investing in.

JTBD 3: When looking at a training course, I want to be given all the information I need to be able to convince my boss to pay for the course.

JTBD 4: When looking at a website for a training course, I want to find the cost of the course that’s right for me, so I can see whether I can afford it or find a way to afford it.

JTBD 5: When researching a training course, I want to see what previous students say about the course, so I can see that peers of mine enjoyed the course and found it worthwhile.

JTBD 6: When I’m looking at courses for specific code frameworks, I want to see what is possible with that framework so I know what I’ll be able to do after I’ve completed course.

So these 6 JTBD are the key things that our MVP needs to be designed for.

But ‘what about those user stories’ I hear you say? WELL, when I’d first got them, I’d affinity mapped all the stories into groups into jobs-to-be-done. Now that I had user research to hand, it validated/dismissed the those JTBD — the validated ones becoming the post-MVP backlog.

All in all I now had:

• Jobs-to-be-done that we’ll be tackling in the MVP
• A backlog of jobs-to-be-done to tackle post-launch

Prototype ideation and creation

Time taken: 8 days

Ideation

Now comes another innovation into our process! Myself and Alex had been talking for a while about different canvases and how we could use them to create products.

The one we’d been honing in on was the Value Proposition Canvas. We saw it as a potential way to not just solve problems and create products based on those problems (what it was designed to do) but also a way to create a list of MVP features.

To test our hypothesis, me and Alex hunkered down in a whiteboard-equipped meeting room in WeWork Moorgate and ran through the process which was…

1. List the key JTBD in the right hand side of the circle
2. List the gains that users will get from completing their jobs at the top
3. List the pains users experience at the bottom
4. Move over to the rectangle, add the name of product we’re creating
5. Add features/content/ideas on how to create those gains (at the top)
6. Add features/content/ideas on how to relieve pains (at bottom)
7. Finally, go back to the JTBD and take the features/content/ideas that solve those jobs directly and add to the MVP features list.

This process took only 1 hour but, together gave us:

• Feature list for the front-page
• Basic information architecture to test

MEGABOOM.

Ideating with stakeholders

Also, it’s definitely worth mentioning that, although Alex is the lead developer on this project, he is also the key stakeholder. As a UXer, it’s key to be very aware of who the key stakeholders are in a project and not to forget about their business (and personal) goals.

This is why doing these exercises in a collaborative, workshop-style setting is so beneficial. The advantages are three fold; firstly all those ideas, experience and knowledge can do directly into the initial ideation of a product. Secondly, it breeds more alignment within the stakeholders — similarly why doing the ‘assumptions canvas’ together as a group is very helpful. Thirdly, and perhaps most importantly, stakeholders feel involved.

As LeanJS is a cross-functional, collaboratively focused team, this works great on internal projects like this. 💪😎👍

Wireframes into prototypes

So we had the bare-bones structure of a page and the information architecture. Now it was distilling what I had in my design back-pocket into a wireframe that the team could take further.

As mentioned above, the LeanJS team are cross-functional and collaboratively focused and this extends into our prototype creation. As we work as quickly/Lean as possible, there’s no need for traditional clickable prototyping tools such as InVision, Axure, Marvel, Proto.io etc etc… Why?

Because our wireframes are coded right from the get-go. My role is to distill the UX basics down using the quickest method possible for Alex, Rich, Horacio and/or Will to take and throw into a React prototype that’s ready to test.

For this, I use Balsamiq mainly because it has standard components all built in that i can click and drag into a screen design. It’s super quick and means I can concentrate on writing copy, which (as the first JTBD about understanding React GraphQL Academy’s level of training) is super duper important. This meant I was able to create the core page templates we needed to test our information architecture and messaging/copy very quickly — in just a few hours.

With these wireframes, they’ll code what everything up ready for my first round of testing. If you’re interested in coding part of this project, never fear Alex will be blogging about it very soon.

Why code prototypes?

The reasons we go straight to coding is really clear — it’s Leaner. The quicker we get our testable prototypes into code, the quicker it’ll be to get the site launched as an MVP.

Not only that, it means UXers have to work alongside the developers from the very start of the UX process. This improves understanding between both parties and therefore mitigates miscommunications, mistakes and just makes things quicker without losing quality.

User testing

Time taken: 2 days

As of right now, we’ve done 2 rounds of testing but to launch our MVP, we decided upon doing one round, iterating on the feedback, then getting the site live. Afterall, digital products evolve as time goes on so best to get it out there and figure out the key problems early!

We tested with 5 target users, specifically developers who’d take the course and tech leads who’d send those developers on the course to learn React.

The key feedback was encouraging but, of courses, changes needed to be made. The key aspect for all users was the curriculum and most users spent their time inspecting the React GraphQL Academy curriculum because:

• It helped users understand the level of knowledge needed to take the course (JTBD 1)
• It reassured users that the course was value-for-money because of the depth of information (JTBD 3)
• That depth of information, showed users who were very familiar with React (Tech Leads especially), that our staff were experts (JTBD 3)

Just a reminder, those JTBD’s are:

JTBD 1: When looking for ReactJS course, I want to visit the site and understand whether the course is at a certain level, so I can feel confident that I wont waste time/money applying for the course.

JTBD 3: When looking at a training course, I want to be given all the information I need to be able to convince my boss to pay for the course.

What’s satisfying about UX at this point of a project is that, through initial research and then user testing, these jobs have now been validated as the key jobs to be designed for. Basically, we found that developers will try to get their bosses to pay for any training at all, and for those tech leads, understanding the level and depth of the training is the number 1 concern.

This is where UX is great — because it was at this point that we knew 100% that these were the key jobs to get right for the MVP. Don’t get me wrong, there were many many more findings that we iterated upon — after all, testing for messaging and copy can be much more nuanced than testing a user flow.

UI design

Time taken: 3days

Now, as you can see in the above coded prototype, we needed to throw some kind of UI on there!

We decided to keep it super simple and utilise our ‘prototype brand’ for LeanJS — check out the ‘Open Source Branding’ blogs for details on that. That essentially meant using the same font as we’re using in the first iteration of the LeanJS website (Barlow, a Google font).

The reason for using this font is highly practical. We needed something simple, very legible, friendly without being too informal but also because it had many weights to choose from. This gives me a high level of flexibility within the visual design without having to slave over font pairings.

Colours wise, we used the ‘React Blue’ as an inspiration and utilising Adobe Color, I created a basic palette that would serve as a basis that we can use and amend into the future.

Creating UI always takes longer than expected but, working as a Lean Team, I would create a design, upload to Zeplin so that Alex/Rich/Horacio/Will could start coding whilst I was still designing up the other pages.

Overview

So, as we’d hoped, we launched our MVP site at the start of August — in time for the lead up to the React GraphQL Academy Bootcamp in London (20–25 August). It was an intense but highly satisfying project, that’s for sure!

Of course, since we have done more user and technical testing — iterating on feedback as we go which means that after 3 more weeks, it’s been evolving quickly. Our brand new React Native and Advanced React courses have also been added, meaning that we’ve also had to re-think IA and page designs as we go…

Needless to say, it’s not perfect. There’s many tweaks and changes the team needs to implement — it’s an MVP so will grow into a swan of a website over the coming months. Afterall, like any digital product — it’s never finished but always evolving!

Visit reactjs.academy now and if you have any questions/queries, please don’t hesitate in contacting us.