How to hack a design conference in 90 minutes
Recently I was privileged to take my team of designers on a trip to Toronto. The idea was to connect with another group of designers working in SaaS to glean insight into their processes and practices and make connections — something the team suggested as an alternative to attending an expensive design conference.
I’m not anti-conference by any means, I just find that there are so many people to talk to and too little time for insightful conversation. I prefer getting in a room with a handful of people and discussing what does and doesn’t work versus shooting the shit with 100+ attendees. All that being said, I still think there is a time and place for going to conferences.
We needed a way to glean insights from experienced teams, apply those learnings to our practice, and eventually be able to contribute back to the rest of the industry with what we learned. Oh yeah, and we needed to do it on a budget. Maybe this was a new approach to professional development, maybe it was a new type of conference, or maybe it was conference hacking.
…it started with a hypothesis; we will learn more about improving our design practice if we visit a team of designers instead of going to a conference.
The Birth of Conference Hacking
Around the end of 2018, our team was discussing options for learning and growth in the coming year. We shared links to books, conferences, and workshops, but ultimately decided there just wasn’t enough budget for all of us to go to these types of events. So, we chose to meet up with a Toronto-based design team that has already gone through our stage of growth.
With the help of other internal connections, we were able to coordinate a time to meet up with the Wave design team. They build a financial platform for small businesses to operate their accounting, invoicing, payments, and payroll. Even though our problem space overlapped a bit, our goal for connecting was more geared towards the processes in the design organization itself.
I’m going to unravel how we approached this as an experiment to determine if it’s something we would do again. Hint: we would totally do it again!
The Experiment
We wanted to try this idea of conference hacking to see if it was something we could do as an alternative to conferences for encouraging continuous growth. So, like any good experiment, it started with a hypothesis; we will learn more about improving our design practice if we visit a team of designers instead of going to a conference.
- First, we proactively determined what topics to discuss during our time together. These topics varied from applying design ops, team structure, and research methods.
- Second, we confirmed a time that would work for both teams to meet in the same place.
- Third, we made sure we had enough time to discuss our topics and that everyone could contribute.
Finally, we needed to determine the criteria for success.
- Were the topics well received, and was the group engaged in the discussion?
- Was it worth everyone’s time
- Were there enough takeaways to justify doing it again?
- Did the time frame seem adequate — did it drag on or did the conversation organically sustain itself?
After the meet-up, from a qualitative perspective, we all felt like it was a success. Ninety minutes was long enough to expand on our topics, but not too long that people were anxious to get out the door. We may not have hit on every topic we outlined, but I would say that the topics were a guideline rather than an agenda. In fact, the topics created more talking points that made our discussion more organic. This lead to passionate discussion rather than a rigid meeting.
The 5 Biggest Lessons
Here’s where it gets really interesting. We were able to walk away with so many nuggets to apply to our current process. Some are extremely tactical in our daily practice, while others are more theoretical in how we approach solving problems.
Let’s sum up our main takeaways into 5 lessons that you could apply to your own team.
While tracking the success of a structural or visual change is one thing, understanding where our product falls short in competitive user experience is a whole new ball of wax.
Lesson 1: Tooling Optimization
We’ve got so many tools available in the design industry that it usually means there are a handful of subscriptions you need to manage. Every design team has their secret sauce of tools and it’s so easy to get lost in the buzz of the next big thing. “OMG have you seen the new plugin for Sketch?! I, like, can’t even believe I lived without it for this long!” Optimizing your processes with the tools you use is a challenge of its own — it’s a never ending balance of cost and production time.
We thought we had a good system at 7shifts using a combination of tools within our process. Seems like we only had it half figured out. The team at Wave was able to use Figma at a fraction of the cost and actually make it easier for designers to collaborate! That being said, we are actively looking into this right now.
Lesson 2: Applying Growth to Design
Growth designers are getting more traction in larger organizations, with more emphasis being placed on sustaining engagement with the experiments they run. We’ve been starting to implement experiments as part of our quarterly objectives within our design team. This has helped us quantify the changes we want to make in the product in an effort to validate that one version is more successful than the other.
I’m excited to take this to a new level with what we’ve been able to take away from the Wave team. While tracking the success of a structural or visual change is one thing, understanding where our product falls short in competitive user experience is a whole new ball of wax. Growth is the new black.
Lesson 3: Selecting Research Methods
Oh boy, this conversation got one of our designers perked up in no time! We love research at 7shifts and it’s an integral part of our product team culture. The tricky thing about applying research to design is that there are so many options! Our struggle was determining what kind of research methods to apply in different stages of the projects.
We weren’t disappointed when we were told there was an entire book about different ways to apply inclusive research! Check out Universal Methods Of Design for your own insight. The previously mentioned designer ordered his copy the following day.
Building a dedicated organization for specialized practitioners needs to start with the 30% capacity of one designer.
Lesson 4: Multi-disciplinary Teams
Building an effective team is something very near and dear to me personally. We recently had an open house where I shared a talk about “The Many Masks Of Product Design” where I discussed how design teams are made up of these different skill sets. Not every designer is made equal, so building a team means you need to know where your gaps are.
One of my biggest takeaways was listening to all the designers speak to a different discipline as if they owned it. Some were running initiatives in Design Ops and others Research or Growth and yet they still had their team to design for. I’m not 100% sure what portion of their bandwidth was dedicated to each, or if all of them were as cross-functional, but it was enlightening. Building a dedicated organization for specialized practitioners needs to start with the 30% capacity of one designer.
Lesson 5: They have the same issues we do
This was the biggest thing we all walked away with. In our Uber on the way back to the office we were discussing how, while they may be advanced in some areas, they were still struggling with some of the same issues we are. On the other hand, we had things we felt we were doing that they could apply and make their process better.
We’re all facing issues, whether it’s the technology our legacy code is written in, the fragmentation of user experience across devices, or lack of involvement of our users and customers. We might not all have Research Ops or dedicated Design System teams, but what we do have is the experiences that got us to where we are now.
Meeting up with another team that has gone through similar growing pains has been so helpful. We’ve been able to highlight key areas that we need to keep experimenting with, what we need to cut, and what we need to expand on. What excites me the most is knowing we’re not alone.
Building a community around your team is one of the most important things you could do for them. The next time you’re thinking about hitting up a conference with your team, try meeting up with another team instead. You might be surprised how much you can give and take from a quick 90 minutes.
