The creation of design models as well as visualization of solutions is for some reason always a subject of great interest among all members of a productive team, be it a manager eager to master Sketch, or a developer who wants to make cool interfaces without the need to go to a designer. But we all know what happens when it comes to actually doing stuff.
Hi, everybody!
My name is Anna and I work for an American company Scentbird NY as a product designer. Prior to that I was involved in developing flagship products in Alfa-Bank design team.
I was probably born under a lucky star but all my life I've been working with the developers who suggest the best product solutions, better than a lot of product managers and product owners. But anyway, my observation is that the earlier you involve developers into working on a particular task, the better off you are.
What you are about to read is actually a blueprint on how to conduct brainstorm sessions and generate not-so-obvious yet effective solutions, which are apparently really easy to reach and not that time-consuming.
Choose the right problem for your brainstorm session. The problem you are about to brainstorm on is supposed to be not too easy, not too hard to solve (if you need to make a road map for 6 months, think about it yourself). Try not to raise issues which you need to agree on with stakeholders(which takes time), choose something that can be accomplished within a couple of weeks.
To answer the question «Why are we solving this problem in particular?» use facts. Prepare all the necessary data in advance and use them in your discussion. For instance, you can talk about how much money is going to be made just by solving this problem. Measure success in dollars or clients.
It's really useful to utilize your understanding of your customers, their pain points by displaying one of the video feedbacks from a client who explicitly said how awkward and uncomfortable their user experience was. That's going to trigger some emotions in the team.
For the session itself the ideal number of people is enough for TWO pizzas to be eaten, not more (about 5–7 people). It surely makes perfect sense to invite the most keen and motivated members of the team.
P.S. It's also a good idea to bring a pizza for the meeting as well.
Divide the session into two parts.
The first part is where you try to come up with 10–12 solutions to the problem. Remember: everybody is to be heard out. Also, be patient, but outline the boundaries, meaning if you feel that a person is going off, focus their attention on the issue at hand.
At the second part choose 3–5 best solutions out of those from the previous part and discuss them in detail. Some ideas could be gone through in a «enactment» kind of fashion to make sure everybody is on the same page.
The rule of thumb is to put down and draw ALL of the ideas using a flipchart and post-it notes or stickers (nothing better than that yet, folks).
You might ask: «Ok, what if I'm working with a decentralized team?»
There is an abundance of software you can use in this case.
like Sococo (common space+video calls);
Miro; Figma and other interactive boards where you can put up stickers, make lists etc.;
VR chat (I haven't tried this one myself but it looks quite promising)
When it comes to bringing it all to fruition keep your team in the picture (about the status and such):
it's interesting for them to see how their own ideas have a real impact on the quality and usability of the product as well as on the money being made by the company.
Some business metrics.
Here is something I see with my own eyes after such sessions.
Engagement and interest
It's pretty obvious that people taking active part in coming up with a solution are much more interested in the execution. This involvement of the team members is hugely beneficial for the business as it eradicates the apathy that a lot of teams face. You see, after such sessions they see the direct correlation between the effort they put in and the result they get.
The technique that I outlined also helps to see a lot of pitfalls at a much earlier stage than usual.
Those brainstorm sessions will help you see all the corner-cases in advance, ideas are going to be generated by your team and, who knows, maybe some of the participants are all of a sudden better legacy-back system experts than you are! BOOM, you've got a home run right there!
Another advantage is that there's going to be much less trolling and friction between the members since none of them is going to pontificate upon the absurdity of solutions because they've been conjured up by their team mates.
Team Spirit
Goal transparency unites the team. First of all, it is another opportunity to shoot the breeze with colleagues.
Second of all, T2M nosedives!
All of the above results in a problem being solved much faster. And if you're prepared enough before the brainstorm and present the results afterwards in the right way the success can even be repeated multiple times.
The odds are that some of the participants might find the session boring and meaningless (they're developers, they want to code for Christ's sake!). Well, it's a really good idea to make brainstorms on voluntary basis.
If some of the points I outlined aren't applicable to your team just take them out or replace them with your own.
And the last, but not the least: if you want your processes to be killer don't forget to collect some feedback from your team.
My way
Hi, everybody!
My name is Anna and I work for an American company Scentbird NY as a product designer. Prior to that I was involved in developing flagship products in Alfa-Bank design team.
I was probably born under a lucky star but all my life I've been working with the developers who suggest the best product solutions, better than a lot of product managers and product owners. But anyway, my observation is that the earlier you involve developers into working on a particular task, the better off you are.
What you are about to read is actually a blueprint on how to conduct brainstorm sessions and generate not-so-obvious yet effective solutions, which are apparently really easy to reach and not that time-consuming.
The process
1. Choose the right problem
Choose the right problem for your brainstorm session. The problem you are about to brainstorm on is supposed to be not too easy, not too hard to solve (if you need to make a road map for 6 months, think about it yourself). Try not to raise issues which you need to agree on with stakeholders(which takes time), choose something that can be accomplished within a couple of weeks.
2. Get your analytics ready
To answer the question «Why are we solving this problem in particular?» use facts. Prepare all the necessary data in advance and use them in your discussion. For instance, you can talk about how much money is going to be made just by solving this problem. Measure success in dollars or clients.
It's really useful to utilize your understanding of your customers, their pain points by displaying one of the video feedbacks from a client who explicitly said how awkward and uncomfortable their user experience was. That's going to trigger some emotions in the team.
3. Get a «Two Pizza Team»
For the session itself the ideal number of people is enough for TWO pizzas to be eaten, not more (about 5–7 people). It surely makes perfect sense to invite the most keen and motivated members of the team.
P.S. It's also a good idea to bring a pizza for the meeting as well.
4. Don't forget: time is money
Divide the session into two parts.
The first part is where you try to come up with 10–12 solutions to the problem. Remember: everybody is to be heard out. Also, be patient, but outline the boundaries, meaning if you feel that a person is going off, focus their attention on the issue at hand.
At the second part choose 3–5 best solutions out of those from the previous part and discuss them in detail. Some ideas could be gone through in a «enactment» kind of fashion to make sure everybody is on the same page.
5. Visualize
The rule of thumb is to put down and draw ALL of the ideas using a flipchart and post-it notes or stickers (nothing better than that yet, folks).
You might ask: «Ok, what if I'm working with a decentralized team?»
There is an abundance of software you can use in this case.
like Sococo (common space+video calls);
Miro; Figma and other interactive boards where you can put up stickers, make lists etc.;
VR chat (I haven't tried this one myself but it looks quite promising)
6. The Aftermath
When it comes to bringing it all to fruition keep your team in the picture (about the status and such):
it's interesting for them to see how their own ideas have a real impact on the quality and usability of the product as well as on the money being made by the company.
Some business metrics.
Here is something I see with my own eyes after such sessions.
Engagement and interest
It's pretty obvious that people taking active part in coming up with a solution are much more interested in the execution. This involvement of the team members is hugely beneficial for the business as it eradicates the apathy that a lot of teams face. You see, after such sessions they see the direct correlation between the effort they put in and the result they get.
The technique that I outlined also helps to see a lot of pitfalls at a much earlier stage than usual.
Those brainstorm sessions will help you see all the corner-cases in advance, ideas are going to be generated by your team and, who knows, maybe some of the participants are all of a sudden better legacy-back system experts than you are! BOOM, you've got a home run right there!
Another advantage is that there's going to be much less trolling and friction between the members since none of them is going to pontificate upon the absurdity of solutions because they've been conjured up by their team mates.
Team Spirit
Goal transparency unites the team. First of all, it is another opportunity to shoot the breeze with colleagues.
Second of all, T2M nosedives!
All of the above results in a problem being solved much faster. And if you're prepared enough before the brainstorm and present the results afterwards in the right way the success can even be repeated multiple times.
The odds are that some of the participants might find the session boring and meaningless (they're developers, they want to code for Christ's sake!). Well, it's a really good idea to make brainstorms on voluntary basis.
If some of the points I outlined aren't applicable to your team just take them out or replace them with your own.
And the last, but not the least: if you want your processes to be killer don't forget to collect some feedback from your team.
