It’s intern hiring time at the lab again! During this time we get lots of questions around our design process and the projects we work on. Since I can’t give too much detail on the projects side, I can share a bit about our design process.
In the TD Innovation Lab, we work in a fast, iterative environment. At any given moment, we can be tackling projects around payments, investments, and everything in between. Since we can’t possibly be experts in all of these domains, understanding customer problems quickly is key.
“After two years of working at the Lab, I’ve gained a huge appreciation for user research and its role in shaping the success of a product.”
It’s pretty easy to look at a couple of FinTech solutions, remix them slightly, and say “Ship it”. It’s much harder to get a deep understanding of where the value lies in a product or service to a user. In the Lab, it’s our job to get those answers.
How we kick off a project
We typically work with business teams to identify opportunities across different business lines. We try to understand how the current business operates, what their key metrics are, and compile any relevant user research. This becomes an opportunity brief, which is entered into a backlog where we rank potential projects. This process ensures that we’re constantly tackling the most impactful projects.
We start new projects every term, and we work in small teams composed of a Developer Lead, Design Lead, and 2–4 co-ops. Our design process has to be lightweight enough to get started quickly. Once we have a problem statement we want to tackle, we jump into research.
Looking at existing research
We look through Google Scholar and other credible sources online. We don’t look at competitor solutions just yet as it might send us off on a wrong path. And we want to avoid getting “inspired” by something we don’t fully understand. At this stage we’re trying to get a deeper understanding of the problem space and get enough domain knowledge to formulate meaningful questions for user interviews.
This stage gives us familiarity with the domain, useful data/stats, questions, and a hypothesis to validate during the user interview stage.
In-person user interviews
When the job isn’t well-defined, the team doesn’t know what to include and what to omit. They design based on logical speculations, not real situations. Instead of targeting a problem like a sniper, they cast a net and hope to catch the value somewhere within its expanse.
Ryan Singer, Head of Product Strategy, Basecamp
I’ve been a big fan of the Jobs-to-be-Done method. There’s a lot to JTBD, but the main thing that I got out of it is that it’s not the product nor the customer, but the situation/context (the Job) that is the key unit of analysis. And the way to understand that context is to talk to people who have recently experienced the situation you’re trying to solve. Instead of asking hypothetical questions, you get them to walk you through their actual experience in detail.
Let’s look at paying bills, for example. We don’t ask, “What don’t you like about paying bills?” Instead, we ask, “Can you tell us about the last bill you paid? Where were you? How did you pay it? On your phone? Laptop? Did you pay one bill or more?”
Working through a timeline of the past month, we’ll uncover situations where people forgot to pay a bill, or paid the wrong account, etc. Having a sense of time and sequence from these interviews give us details from which to craft our future solutions.
It’s the little nuances and details that often hold the germ of a great solution.
When we jump into designing flows, we can look back on the interview notes as we evaluate our designs. We can ask, “Am I making the right tradeoffs and prioritizing real problems? Did the user need something to be faster, or more clear?” Those could be opposing design choices; so knowing what’s important and when is a huge help.
This stage gives us the understanding of what matters to users in a given situation and what trade-offs they’re willing to make (i.e. speed vs. clarity).
Unpacking the research with Google Ventures Design Sprint
We’ve adapted the Google Ventures Sprint process to last 1–2 days instead of the suggested 5. We first unpack all the 3rd party research and interview summaries to the rest of the team. We then draw a customer journey map and re-evaluate if our initial problem statement still holds true.
Sketching the solution
We’ve skipped this phase of the Sprint Process on a few projects, but I keep going back to it. There’s something special when devs and designers all contribute at the initial stage. The solution sketch itself is an interesting constraint. You get one piece of paper to sketch out your concept, and then you put it up on the wall for the team to vote on in silence. By no means will you have the full solution on the spot. But, it’s really cool to look back on the sketches in four months’ time and see how the final solution has the kernel that started on that piece of paper.
Next, we do some competitive analysis and check out other solutions in the market. Once you understand the customer ‘Job’, and have a clear problem statement, you can step outside the industry to get fresh ideas and find interesting patterns to pull in.
Now it’s time to prototype
We try not to spend too much time in theory, instead moving on quickly to build a prototype to start getting real feedback. The Lab has done quite a few projects over the last few years and in that time, we’ve built up a Prototyping Design System that lets us build prototypes quickly. This system includes several defined components that can be used as building blocks for new solutions. As we learn something new that works, or if we need to craft a new component, we add it into the System for future projects.
Time for testing
Once we have a working prototype, we show it to users to test our hypothesis. We find little value in showing users wireframes and rough mocks. They need to see something coherent (even if it’s lacking features) to give useful feedback.
At the early stages of testing, we’re mostly interested in validating that we’re on the right path and solving the right problem. Our prototype acts as a conversation starter and we find that users are really good at recalling unique details of their own workflows as they’re exploring a new solution. We sometimes get our best ideas out of the limitations of our early prototypes. Hybrid user testing/research sessions like these are really valuable to us.
Capturing Feedback Data
This process of build, test, iterate basically repeats for 4–5 sprints, depending on the project.
As we move into the latter stages of testing, we need to switch from exploration into validation mode and start getting real answers. Is feature X working? If not, is it because we screwed up on the execution, or is it not as important as we initially thought? We need to start getting precise here. We only have a few sprints left and we’re making important decisions as to what stays or goes from the product.
We find Trello to be a simple way for the whole team to see the research all in one place. By scrolling through the boards, you can see the evolution of a project and all the decisions that were made based on real feedback and testing.
We run through several iterations of the build and test loop, getting more and more feedback data. You’re never really done with a digital product, but we can tell when we’re ready to wrap up when everything is mostly working and people are getting excited about using the solution in the real world.
Wrapping up
We’re constantly trying to improve our design process and get better at building and validating concepts. I’ve personally gained a huge appreciation for research over the past two years after being involved in over 100 interviews across different projects, and I find it to be the most useful tool in getting a deep understanding of the problem and contexts users find themselves in. Once you have that understanding, you can pull in all the awesome patterns and tricks from the design community to build out your solution!
Let me know if you have any questions! In the meantime, feel free to follow the Lab on Twitter, or consider joining the Design Team!
