Legoland, Ikea, and doing UX work

DataBS Conference Update: Get your tickets for the Sept 24th event! So far slightly over 80 people have signed up to attend. I'm slowly working on putting together the speaker/talk profile pages in a way that aren't eye-destroying ugly.

Two normally unrelated things happened this summer that has been bouncing around my brain for a while because at work they splat together in a UX kind of way.

First, just over the weekend, I was putting together a dresser from Ikea. It might be surprising since I'm known to be an avid DIYer, but very much enjoy putting together Ikea furniture because they're so well designed. Given a very limited palette of materials, mostly wood, particle board/MDF, and metal, and a very curated collection of fasteners, primarily cam screws and dowels, they create things that are surprisingly sturdy for very low prices. Moreover, the designs and instructions have clearly been refined over the years to minimize the potential for mistakes by customers. I admit I learned a non-trivial amount of woodworking principles over the years putting their stuff together and seeing what patterns work.

In contrast, if you've ever bought super cheap furniture online, you'd probably be familiar with flat pack furniture coming out of places like Vietnam that are built around metal tubing frames with thin particle wood boards and fabric drawers. These pieces of furniture mostly eliminate the concept of wood joinery with dowels and cams with simple screws and threaded bolts. These manufacturers also have taken pains to simplify their assembly process by clearly labeling screws and parts so that they don't have to resort to using broken English instructions. While quite a ways different from Ikea, they're still serviceable.

The other unrelated thing was we took the 6 year old kid to various kid/family things, one of which included the usual small kid-friiendly amusement parts that are a bit run down and over fifty years old. We also went to Legoland. The whole time we were there I was admiring the obvious signs of careful design that went into the park. The safety protocols were strictly enforced, with usually two or more operators per ride that clearly did safety checks before anything moved. The line spaces were planned to provide shade and offer amusement for kids. The staff had electric fans or shelters to keep them out of the heavy sun. They even had specialized motorized safety barriers to prevent a kid from accidentally getting somewhere they shouldn't. It was a huge difference compared the "One bored teenager melting in the heat not bothering to check seatbelts" at the older parks.

So the common thread between these two things is attention to design and continued refinement. Obviously, there was at least one person at Ikea and Lego that put energy into deliberately make the experience of customers better in some way. So the question I have in my head is... did those designers use data and metrics to help them along in their design process to get them to the "nicer version"?

The first question, what helped them get to the "nicer version" of a ride? A lot of this stems from having worked my entire career with teams that are pushed to launch quickly. You can have UX teams repeat a thousand times how users continue to struggle to use the product, but they typically don't have the power to stop a launch. I can cite a bunch of metrics. But at some point, if the team fails to improve things despite the feedback, management will decide that they've spent too much money developing the feature and need it to show some return on investment NOW. So unless the team nails the design very quickly, there's very little motivation to attempt to get to the "nicer version" on initial release. Doing incremental improvements is often a slow process of experimentation, so it takes a lot of organizational discipline, culture, and executives who care about user experience, for an initial launch to be delayed significantly.

But the second question I have is probably my primary interest – what sort of data, if any, had informed these designs? As a quant UXR, it's trivial of me to wander around and think of things that could be measured to shed light on a question. Queue times, the flow of crowds, customer satisfaction can be surveyed, ride volume, accidents, all that and more can be quantified. Disney is quite famous for using such data in the design and optimization of their theme parks. But if I'm going to be honest about it, the true genius is coming up with ways to analyze the data to make good design decisions – and I'm not sure I'm any good at thatpart.

I can clearly see a trail of research that hypothetically shows that users hate waiting in line for rides the most — satisfaction surveys, wait time data, typical number of rides taken by a guest, there's multiple ways of analyzing that story. But how does one make it better? A lot of quantitative UXR work pretty much stops at the point of identifying the symptoms of the problem because that's where our existing data ends, leaving the answer as an exercise to the designers and stakeholders.

To dig deeper into the causes, enough to figure out potential solutions, takes a lot more work and precious time. It means having hypotheses and collecting new data. It also takes insightful thinking on the part of the analyst to figure out the right experiments and questions to answer to help come to a design. It also means doing ... uncomfortable(?)... things like interacting with other humans! And obviously, it requires lots of domain knowledge to come up with the opinionated views necessary to do the research.

Anyways, these thoughts have been bouncing around my brain for much of summer because none of this work is the familiar quanty stuff I spent most of my career dealing with directly. Writing code to count stuff is my bread and butter. Having enough opinions about a system to direct measurement in hopes of actually fixing the problem? What kind of black magic is this? You mean I can be wrong and have to take calculated risks?

Probably the sooner you realize that's the true work in "product work", the better.

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.

About this newsletter

I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.

All photos/drawings used are taken/created by Randy unless otherwise credited.

• randyau.com — homepage, contact info, etc.

Supporting the newsletter

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

• Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
• Send a one time tip (feel free to change the amount)
• Share posts you like with other people!
• Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
• Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!