So i just realised something. When I type in the phrase "concepting", it's almost always accompanied by a red squiggly line beneath it. Mocking me for using non-existing words. I even checked to see if it isn't something us Dutchies came up with. It isn't.
By the way, "Dutchies" isn't a word either.
I myself have enjoyed so-called "concepting" projects in the past. So much so, that I've just added it to my | LinkedIn | headline. And since I've decided to become a freelancer, I thought it would be good for me to explain what I mean by this ambiguous phrase. I mean if it's a service I offer, then I need to get its proposition clear.
Risk and reward
As designers, we're always throwing around phrases like "voice of the customer", "user-centered" and "Is that a component or a pattern?". But at the end of the day, no matter how many customers we show our idea to, all we're doing is minimising risk. The risk of building something our customers don't need and/or understand. Even if we find the time, and the money, to combine both quantitative and qualitative data of over 1mln. people, we're still not 100% sure if our idea will add value for everyone. Let me illustrate this with an example that we're all familiar with:
You're in a meeting with your PO and data analyst. The analyst mentions that the CTA on the landing page falls below the fold quite often. She believes we're missing a significant amount of CTR because of it (image 1).
Let's consider two scenarios here. The most common option would be to trim the copy in the paragraph above the CTA, so that it stays in view more often. Do an A/B test and see if the CTR goes up or not.
But of course, as a designer, you probably have a couple of other ideas locked and loaded. The border around the header is too old school, and you and the design team have already decided that needs to change. So why not change it now? And while you're at it, maybe even make the image look nicer on the screen (image 2). The design system team is on board of the component changes, so the time is now! Let's take the leap!
In this second scenario, the analyst will probably advice against an A/B test for the medium risk scenario because you're changing too many variables. And even though you understand, you don't want to get to the medium risk scenario by testing every single step. That'll take too much time. So here, your team, together with other stakeholders need to make a decision. Which risk are you willing to accept for the reward you're after?
Mastering concepting
To me, concepting is exactly that mindset of risk and reward but on steroids. It's having an idea, and timeboxing how much value it could potentially have. The key here is to focus on all the assumptions you've made by coming up with this idea. These are the questions you need to check with your users and other stakeholders.
Now it's great if these concepts start with a clear problem statement. But let's be honest, sometimes it's a strategic decision and you just have to roll with the punches. In these scenarios it's up to us to gather insights quickly that could make the concept more focused and at least fix a couple of existing problems. So depending on the concept at hand, such a project could look something like this.
The Kick-off
Assuming there's already a concept to be tested, this kick-off is where you ensure all the right people are aligned on the following points:
- What is the goal of the concept? (Which problem are we trying to solve? And this can be a business problem as well)
- What is the concept?
- What's the time frame we have to run tests?
- What are the main assumptions we need to validate?
- Do we have a clear overview of all stakeholders?
- Next steps
The most important parts of this kick-off is that everyone understands that your team is there to identify and potentially minimise risks before you start building. Risks that eventually could just be accepted by the stakeholders instead of mitigated.
So, what now?
The following schedule is based on a project I did with some amazing colleagues. We came up with the following setup for a concepting project with a tight timeframe:
- Monday: Take an assumption from the prioritised list and come up with a solution that could provide insight on the hypothesis
- Tuesday: Design/build
- Wednesday: Test on site and potentially update the prototype at noon to do another test directly afterwards.
- Thursday: Test day
- Friday: Breathe...
At the end of this project, your team will be able to provide clear insights on all potential risks of the solution. Furthermore, you can advice on how to deal with those challenges when you start building.
Concepting: The proposition
So concepting to me is rapidly gaining insight about an idea to improve its chances out there in the wild. It's like raising a child. You can't always control everything, so you focus on the things that matter most to their success and happiness.
If you have a project or team in mind that could use this mindset, feel free to reach out. Even if you just want to have a chat.