Bricks to Product: How Lego-Building Techniques Transfer to Product Design
A few Christmases ago, I bought Legos for my two kids, and guess who was put in charge of assembling their dream designs? Yes, me. I love how I can build anything with Legos: Cars, castles, dinosaurs. And my kids love that we can use Lego to realize their imaginations. They often put in random requests: “Mommy, can you build a pony for me? Mommy, can you make me a Batmobile?” As we build our Lego structures, I find myself using many of the same techniques that I use in product design.
Keeping the Big Picture in Mind
One request was the most complex yet: “Mommy, can we build Gotham City?” Understanding and visualizing something as grand as a city is just the start. Every city moves and grows, so it was important for us to anticipate the growth of new buildings, villains, transportation, and storylines that might be required in the future. Factoring in the potential future state was an essential part of our design.
Fortunately for me, design engineering is something I do every day as a product manager. The design of every new feature requires careful assessment of existing functionality and potential impact. Identifying the users and their expectations around product dictate design choices and feature development. This is particularly important as we build large frameworks that touch a company’s ever-changing business landscape, decision-making organization structures, and processes. A typical Workday customer could have over 700 business processes and more than 30 items that dictate their organization structure. This could be anything from global operations to cost center management. It’s not always possible to evaluate and understand all the use cases, but it’s important to keep scale and extensibility in mind as we build frameworks.
Understanding your target market space and determining its impact on your product vision is key to building successful products that stand the test of time. This also allows your development teams to design for the future, rather than building quick, dirty solutions that fix a small problem for today but increase overall technical debt.
Prototype to Validate Design
Humans are visual by nature, and often need something tangible to refer to in order to fully understand complex designs. When it comes to Gotham City, building the city without planning ahead could have led to misjudgments that cost hours of build time and precious moments playing with my kids. Prototyping as a concept can be applied almost anywhere: It lets us as humans quickly validate an approach before investing the time to build the actual components. I quickly put together Lego pieces to show my kids what the city would look like, and by seeing it, touching it, my kids gave me lots of feedback that I wouldn’t get by just verbally describing what we should do. It was a valuable early life lesson for my kids to understand the merits of quick feedback and visualizations to avoid disappointments.
Similarly, in software development, prototyping is the best way to validate whether the design meets the requirements of our customers, stakeholders, and even our own team. A basic prototype points us to the north star and enables us to visualize the most used scenarios without building out the actual flows. This increases developer productivity, provides our customers with a visual model that they can provide feedback on, and reduces time to market for important features. As product managers, we often struggle to perfectly pinpoint our users’ needs on the first try. With prototyping, you can provide your users and your team with a reference frame to further define their ideal state, while at the same time generating incremental value for them.
Understand the best case scenario for your product flows and generate a consumable prototype that can be shared with internal and external stakeholders. Gather feedback and iterate to build a successful product that meets your customer needs.
Break Down the Structure for Detailed Construction
Once Gotham City was prototyped and approved (by my kids, of course), we all got to work. I noticed that their work seemed defined by their attention span. As their eyes wandered, they would suddenly drop what they were building and start working on the next shiny part of the construction. The project was large and their attention span relatively short, and the result was that they quickly amassed a scattering of incomplete formations that didn’t quite fit together.
In product development, we can be similarly tempted to let our focus drift when we don’t properly break down work into its constituent components. Here’s where it’s important to come up with architecturally sound designs that address all corner cases and can scale for the future. Building monoliths would make it impossible for future changes, while focusing on a modular design allows for flexibility and scale. Encourage UX designers and researchers to think through the product flows while keeping your architects in the loop to determine feasibility. A well-thought through product design and architecture can be reused, and also allow product managers to think big while executing on smaller roadmap items.
A key technique that could be used to determine ideal components would be to focus on personas and their respective use cases. This focus helps dissect the feature and determine differences and overlaps. It also helps architecture decisions such as sharing processing parts while building distinct user interface components for your user personas. A phased approach with clear objectives allows product managers to define a user journey that can then be broken into components.
After our first construction attempt, I asked my kids to help me build the remaining components of our city. We identified the structures, villains, and vehicles we wanted to build, and defined a minimum number we would build within each category. Then, we got to work on each component and compared them to make sure they looked relatively similar. By the end, they built the last building all on their own.
As a mom, I put my kids in the center of the Lego structures I build for them. This makes them feel special and encourages them to learn and build more structures on their own. Similarly, product managers should always put their customers in the center of their product offerings. This helps with product adoption and helps with customer satisfaction with our products. These three techniques are just the starting point to achieving that goal. Keeping the big picture in mind and prototyping solutions and designs allows for a quick and iterative product development lifecycle that encourages early customer feedback. Execution then becomes much easier and you will be guaranteed a higher product adoption and usage rate. By building on top of these fundamental principles, you can certainly have happy customers just like my proud Lego-building kids.
“Everything’s impossible until somebody does it.” — Batman
A brighter work day is just around the corner ☀️. Explore career opportunities here. For more #WDAYLife content, follow us on Instagram, Facebook, Twitter, and LinkedIn.
