Keeping the design process collaborative

I have been at EF Class since 2016, when I joined as a Product Designer. During my time here, I’ve been given a deep insight into the different types of teaching and learning experiences around the world. When I first joined, it was surprising to me how robust the design process was and how organic and collaborative it felt. I thought this would be interesting for other designers working on products too, and so I’ve decided to share this with you.

A little about EF Class

In a nutshell, EF Class is a digital product focused on English teaching and learning. It offers a vast collection of material that teachers can use to run lessons in the classroom or to send to their students as assignments to do at home. It collects the students’ results and surfaces them back to teachers. This then allows teachers to have a better view of their students’ progress and gives them the information they need to decide on what to teach next.

This is obviously a very summarised version of what the entire product does. We have teacher and student versions of the app, a CMS system to support all content production (produced in-house), as well as a web and iOS app (the list of elements goes on).

What all of this means to me

I work as part of a team of three designers. Our responsibility is to produce the best experience we can to support any of the interactions that occur in a classroom environment. In order to do this, there are a few phases we go through in any design work that we do. This varies on a project/feature basis and can be a longer or shorter process. However, the process usually follows these steps:

Research

Usually design is one of the first teams to be involved in new projects because we lead user research most of the time. We try to involve experts from our team (academics, developers, and product) so that we all share the same knowledge and all get to listen to our users.

Once we have an understanding of the problem to be solved, we get into the elaboration phase and user experience exploration. We might run UX workshops or design sprints with contributors from each area of expertise and from there, produce wireframes and prototypes of potential solutions to test.

We test these hypotheses with users and iterate until we feel confident that our solution will be efficient and bring value to our users. When we reach this confidence level, we map the MVP and any other possible subsequent releases that can be derived alongside our product owner.

We then start with our ideation phase.

The ideation phase is the focused continuation of the elaboration process. During this phase, we produce high-fidelity interfaces, prototype interactions, and animations. We take into account differences between platforms, and we document our thoughts and design deliverables in Zeplin and Jira. We then perform usability testing where possible and practical.

To keep everyone in the loop of events and decisions, we run design stand ups alongside this whole process. These sessions usually take between 20 to 45 minutes at most, and aim to give a ‘show and tell’ of progress in our design work. This allows everyone to give feedback, and flag any issues and concerns — in particular anything we might not be aware of from our tech teams that could be a limiting factor. We find that this really helps us design wisely, and reduces misinterpretation during implementation.

At the same time, the development phase overlaps with the ideation stage. We run example mapping (three amigos) sessions to capture the rules and behaviours of the user experience and system behaviour. Usually designers pair with developers and testers to solve problems, address newly discovered issues, or look at edge-cases which arise during the technical execution. As the building process progresses, we help define stories, create assets, and maintain communication between teams.

Wow, that sounds like quite a lot of work?

It does, but in reality we try to work on small problems - one at a time. We are always trying to get better at this — we’ve learned over the years that it’s better to work on smaller problems and test them as quickly as we can.

What have I learned from this process?

Be open to change and experimentation.

The last two years have taught me that with processes, there is always room for improvement. Teams need to be open to experimentation and changes to their methodologies — ‘scrum’ vs ‘kanban’ vs ‘whatever you want to have’ — so they can learn what works best for their efficiency. It is important to have retrospectives and analysis points where we can all reflect as a group on what works well and what needs improvement.

We are all working towards the same goal.

Although we don’t have a massive team at EF Class (we are about 25), we still find ways to miscommunicate. We need to constantly keep reminding ourselves why we started working on something and make sure to bring everyone onto the same page. Nobody is perfect, so you can’t expect to have the perfect team — but you can always help people improve their communication skills.

At the end of the day, the success of a product is only achieved through the effort and work of the people that build it. It’s not always easy, and there are bumps along the way, but that makes it exciting and challenging to me. So with every problem that I help to solve, I get more reassurance and confidence in the people and product that we build every day.