Innovation in blockchain startups: case study of a design thinking project at a venture accelerator
In this piece I share a case study of a startup team I worked with recently, one problem-solving method we used together, and some reflections on my initialization at a venture accelerator. My hope is that other teams working in Web3 will be inspired — and will try using design thinking to unsnarl problems and dig into their products, protocols, and users, too.
Linnia is a protocol-focused spoke, or start up, housed within the ConsenSys venture studio. The team learned to use design thinking and methods to transform their development to be user-centered — and baked that into efficient hackathons and a new data product they’re testing with clients.
A scaffolded process enabled team members to learn about human-centered design in manageable steps so they could apply it to their work. First in coaching calls with two team members I modeled collaboration, empathy, and defining the problem to solve: the project needed to focus the direction of work and wanted to use user needs as guides.
Next, the full team engaged in a remote prep session to introduce concepts of empathy mapping, alignment, and the value of identifying convergent and divergent ideas. Finally in an in-person workshop we dove into creating human-centered design guidelines by focusing on the problems their actual users have, and connected the ideas meaningfully to their upcoming decisions about how they might solve them.
The Linnia team incorporated user-centered design practices into their public-facing hackathon events, based on those learned from the design facilitation sessions. They’ve now guided over 70 participating engineers to develop their solutions using design thinking exercises.
The team’s community manager shared, “We used design techniques during the hackathon and it had a very large impact on quality during the event — Most teams completed prototypes in their projects!”
Turns out, user-centered design provided hackathon members, many of whom had not met before, a shared reality, language and methodology to express a problem to build around. As a result the ecosystem of decentralized applications around the core protocol is being built and tested quickly using explicit scopes, not implicit assumptions.
As their product line grows, the Linnia team is preparing to request funding from the ConsenSys’ investment Committee — and has been speaking with possible clients for a data warehouse product that came out of the team’s in-person retreat.
Next, they’ll be using design thinking to help them prioritize more features — creating a roadmap that they all understand, can test, and that looks clearly towards success for their dApp-building protocol and product that’s heading into the market.
The whole team participated in an asynchronous 1-hour prep session where we collaborated using Mural, to introduce concepts and get baseline work done to set the stage for our deeper in-person tasks. Then, we did a 3-hour in person workshop where we dug into their problem space. Key observation: you can get a LOT done remotely online, and it put the group a leap ahead when it came time to work in person.
Below I detail one method that stands out from our work together, in case you want to try it with your team (or if you’re a ConsenSys member — call in a Design Facilitator to design this experience with you!).
Given the objectives and timeline of this team, I used a scaffolded approach and a limited segment of one design process to simultaneously educate and keep them on track creating testable ideas. We focused on the “first diamond” — user needs, problem definition, and creating design statements. Rather than overwhelm them with teaching, I wanted the team to be able to incorporate on what they were experts in.
Knowing their next step was a day of buidl, eg an internal hackathon, I trusted them to apply the insights we uncovered in their next steps — and they did. Key observation: trust that people are smart, and give them tools to help them apply their smarts.
Method: Mad Libs! Also known as Templates or Fill-in-the-Blanks.
This design method is excellent because it’s deceptively simple, incorporates high-value information into a bite-size format, and leverages the power of storytelling to be memorable.
We used madlibs in a few instances. First, in our remote session to begin to define a user-centered project vision statement:
Linnia is __X__ and it does __Y__ for __Z__ people.
In workshop we started using a “How Might We” challenge to cook up ideas that were completely focused on what someone using their protocol would want, experience, and feel:
How might we redesign ____(pain point)____ for ____(user)____ so that _____(user focused outcome)________.
To end the session, I brought in a multi-step design guideline madlib in workshop to get us to: incorporate a human-centered approach to their existing product ideas, compare the value of a few new ideas, and define testable ideas:
We believe that by enabling ___(solution, action, use case)____, that ___(user)___ will ____(user-focused outcome)______, and we’ll know we’re right when we see _____(result, metric, indicator)_______.
Lastly, I loved learning that the team passed it forward, and began using this method in their hackathon to create focused design challenge statements using “How Might We Improve …’:
How might we improve _(problem in the domain)______ for _(user)___ , so that _(user-focused outcome)______?
Try it at home, work, or school!
These are deceptively simple-looking, but you can absolutely try this with your team. Set aside an hour, walk through your users and think about user-focused outcomes, and then give everyone a chance to fill in as many of these as they can. Look at all of them together and decide on a few that seem the most promising. Prototype, test, and repeat.
What goes into these design guideline madlibs? User research, business case analysis, and the sparks of intuition and applied creativity that make up innovation. The secret is: after you’ve written it, you have something make informed decisions from while you’re in development and to validate your work against later.
When it comes to solving the kinds of complex problems that startup teams are facing, digging in methodically and carefully is ultimately a time-saver.
Listing what you’ll try, for whom, and why gives you unparalleled insight into your problem space. It sets you up to try to solve the problems in your next phase of work. It gets people on the same pages and gives you a clear “what we tried and why” to debrief afterwards. I can not overstate the value of having a clear design statement for your work!
As a practitioner of design thinking in a venture accelerator, I knew I had the opportunity to test and prototype my methods.
The design challenge I identified for myself was: how might I enable blockchain startups to innovate, identify high-value problems, and move development forward in a user-centered way?
This team in particular was hoping to do feature prioritization, extrapolate insights from a limited (but existent!) user base, align vision and mission to their strategy, and develop a guiding principle to drive everyday choices in their work. They wanted to integrate human-centered design principles as an ongoing practice to ensure their work gets used.
My hypothesis was that giving the group a balance of education, hands-on practice, and moments to reflect would create a learning synthesis environment which would allow them to take skills forward and have useful decision-making frameworks after our session. In reviewing the case outcomes, I think this validated.
From retros with the team lead, I know it wasn’t a magic wand, and that the group is interested in iterating on what they learned so as to further leverage human-centered design to sharpen their output. Key observation: design isn’t a one-and-done activity — you can always understand more about how people might use what you’re creating, and why.
Personally, it was my first day at ConsenSys that I connected with Evin, the Lead at Linna, as my contact for my initial project. As a brand new employee, it was great to know from go that I’d have something meaningful to dive into, and to be honest I don’t think there could have been a better fit. I had thoughtful, fun, and efficient planning experiences with Evin and the whole team, and seeing the impact of two workshops on projects that operate in realtime is so inspirational.
Key observation: For team leads looking to leverage design thinking, I’d encourage you to share your goals, both high level ones and specific deliverables, as well as your challenges with your design team. This allows a designer to dig into your needs and perspective and come at the design challenge you have as a collaborator.
This was an incredibly fun project for me to work on because I was able to partner — as I soon learned, the bar is high thanks to the brilliant minds that make up the ConsenSys mesh so going deep together is key.
Finally, it was an incredible experience to get to airdrop into a team — literally, I flew to a different state and drove to a remote mountain location! — go hard on design with them, and offer as much support as I could muster. They were super kind and welcoming to me as an outsider, and as a new employee I was so appreciative of both their generosity and the opportunity to do work I love with people who were open to it and to me. Key observation: relationships matter in our work.
I’ve since supported several other teams and initiatives, have tested a few more methods, and am constantly excited by the level of thoughtfulness and the breadth of projects on deck at ConsenSys. I’ll share more writeups in the future as I process these.
My team, Design Facilitation, works with ConsenSys studio’s ~40 startups, enterprise projects and on internal innovations — and we’re hiring, as are many teams at ConsenSys. If you want to get involved in the hackathons discussed above, follow Linnia on Medium here.
~ Hadassah Damien is a design facilitator at ConsenSys as well as a technologist, performing artist and curator, economics researcher, and urban bicyclist.