In 1926, Austrian arthitect Margarete Schütte-Lihotzky designed the Frankfurt kitchen [Wikipedia], a kitchen concept aiming to be affordable and enable efficient work.
Image: Frankfurt Kitchen (Wikimedia Commons)
It was considerate, well designed. Groundbreaking in many ways, and influential in some. It made great use of space, brought high quality and top design to people at very affordable price levels. (About 10,000 units were installed in Frankfurt at the time.) All great, right?
But people struggled using it. And that’s where we can learn something for the connected kitchen.
“Unaccustomed to Schütte-Lihotzky’s custom-designed workflows for which the kitchen was optimised, they often were at loss as to how to use the kitchen.”
“It was frequently described as not flexible enough—the dedicated storage bins often were used for other things than their labels said.”
“Schütte-Lihotzky had designed the kitchen for one adult person only, children or even a second adult had not entered the picture, and in fact, the kitchen was too small for two people to work in.”
These quotes are pulled straight from Wikipedia. To me, they represent pretty much the challenges we face with smart/connected kitchens – and more generally speaking, homes – today.
As connected homes and kitchens today are often pretty much proof-of-concept stage, they suffer from similar issues:
- People need to re-learn how to use their kitchen to take advantage of the added features; at the worst case, re-learn how to perform even basic functions.
- People use their tools in unpredictable ways. Customer journeys only take you so far. If tools and processes are overly scripted, they can be too inflexible to use in a real-life setting.
- Use patterns change both over time and throughout a person’s life. Shared housing, family life, single life, temporary living arrangements – and all kinds of variations and combinations – all need to be served equally well in something that like a kitchen could need to last a generation or longer.
Connected kitchens (and homes) need to be ready for these requirements. They need to be usable within existing contexts and workflows (be retrofittable), designed to last (be upgradeable and work without software maintenance), and work for a wide range of potential users (be flexible and adaptable).