Learning fast, Learning slow — being intentional with building software

I’m part of a small team set up to explore future customer problems and look at where the industry is moving towards. We try to translate research findings into our software development, reframe conversations to centre around user problems and apply creative problem solving to our work.

We use aspects of agile and lean methodologies to create a collective mindset and approach and the following are our working philosophies we live by.

How we learn fast

Start simple
We start with building in HTML and CSS as they are the bedrock of the web. It is so easy to get distracted by the latest technology or fancy widgets. We believe in developing services that will last as long as possible and be accessible to everyone. So we build things quickly, focussing on accessibility and robustness early on, and investing our time on refinements and enhancements when we have confidence that they are needed.

Build as little as possible
Alongside our exploratory research interviews, we utilise existing software or tools to test many assumptions at once. When we wanted to build a bespoke tool for our users, we started by hacking Trello with our own API’s. By doing this, we were able to set up a system in a week, and allow it to be used over the course of 4 months. This gave us a much clearer view of the ease and frustrations of the system used over a longer period of time versus just a one-time usability testing session.

Solve problems creatively
Experiments are not limited to the software tool we are building on. We can also get useful information from a twitter poll, click-through prototype or a fake door on a marketing site. When we have a strong understanding of how our users complete their daily tasks, we are able to build them useful tools such as a browser plugin in a few days. By testing ideas creatively, we save time and effort by not building tools that do not solve the right problem. Even if the service provided is a web page or an app.

How we learn slow

Build relationships
No team can be successful on its own. Building meaningful relationships take time. We’ve found making the effort to connect and catch-up with stakeholders and other teams beneficial to our existence. They help influence cultural change, provide their expertise, and inform our work with in-depth knowledge that we might not have. We have a regular showcase to share how we think about their problems, how we’re solving them, who we’re working with, and what we’re thinking of next so that others can get involved.

Find the real problems
We always try to start with the user and business problems. People often have the temptation to jump to solutions before identifying the underlying problem, but we can take these ideas and use them as the beginning of a conversation. We reframe them around questions such as “What problem is it solving?” ”Is it still a problem?” “Is this a user problem or a business problem?” This allows us to get to the root of what they want to achieve.

We use those answers to begin to draw out the full user journey. We later conduct exploratory research interviews; pulling out missing gaps, user problems and deeper insights into behaviours and attitudes.

Reflect on insights
We regularly reflect on what we’ve learnt both in our experiments and as a team. There are many small learnings from our failures but we are also conscious of the bigger questions and goals to address. We take intentional pauses to process what we’ve learnt so far, as we can get lost in continuously producing work all the time. We also don’t wait for our retrospectives to reflect or to vent. When there is conflict, we immediately find a space to explore it together and find ways to tackle the issue.

Slow down to move fast

To be driven by a deep understanding of our users’ goals, we need to intentionally slow down, step back and really understand what we’re trying to achieve.

Drafting a flow, typing out code, and/or gathering feedback is something we can do faster each time. What takes up time is building relationships, analysing and integrating insights into producing new functionalities, and reflecting on learnings we might have missed.

It’s not constantly building new features that is most valuable. It is testing an idea as quickly, cheaply and easily as possible, to see if it is worth investing in. That is the most valuable use of our time.

This post was made better by these people and their brilliant brains.
Christopher James, James Cook, Lloyd Killmore, Rebecca Hansen and Rob Lloyd