This semester of grad school, I’ve been tasked to create a product that both solves a need and that we’d enjoy producing to sell. Since I’m in a wedding planning mindset, I’ve decided to spend some time looking into the wedding guest book and how to get guests better involved in just what that guest book could be. I ran a short survey asking people to share their opinions on the subject and started prototyping some ideas from all the wonderful feedback. I’m looking into creating customizable card sets that prompt guests for a short anecdote about the bride, groom or their family. Wedding guests bring a rich history into a single space for an evening, and what a better place to share that than the guest book itself, giving the couple a wonderful collection of stories to take with them—the stories that brought them to the wedding day.
The images above are some first round prototypes of my product concept. If you’d like to learn more about this project as it evolves towards an Etsy launch, please leave your email here.
This is how I had always approached the notion of code literacy for interaction designers. That designers should, at the very least, understand how the technical components of a given project will come together to support its design. What I am quickly beginning to realize however, is that this was a rather simplistic reason for learning how to code. The true benefit of leaning code is more akin to the ability to use 3d Modeling tools in architecture. That is, the ability to prototype.
The Hammer Is Not the House.
I’ve been thinking a lot lately about “The Design Process” and currently how frustrated I am by it. Since starting school I have seen hundreds* of models for this process. The double diamond: Four D’s approach, IDEO’s human centered design toolkit, the who, what, where, when, why model, listening labs, the business model design generator, the RSVP cycle, etc, etc. I feel like my brain is about to explode while trying to be discerning about the best method to implement, not to mention the shear volume of acronyms associated with each method. I have to ask, publicly, why?
Alex on Framework Fatigue.
A Little Background:
Employers are demanding a workforce that can engage with complicated, ill-formed problems. Executives want individual contributors that can embrace volatility and unpredictability, while crafting narratives of the future. Brands are realizing success when they try to empathize with — rather than understand — their customers. This — not the production of beautiful things — is what designers do best, and it is the value they bring to organizations. Producing stunning creative output it only a tiny part of what it means to be a designer, yet aesthetics continue to be the only part that we herald as valuable. But it’s these other skills — empathizing, systems thinking, storytelling — that describe a successful career in design.
For many of us — perhaps even all of us — are born with the abilities to empathize and tell stories, to dream of futures that don’t exist and to visualize new ideas. It is only against a constant drumbeat of STEM-focused primary education do we learn to embrace only the rational, to focus only on analytical thinking, to ignore and temper emotion, and to reduce problems to root causes — to seek explicit causality, rather than broad ambiguity.
Since the beginning, people think of interaction design as a field input laden with mice, keyboards, and screens. They see our work floating in the ephemeral space between their screen and the information highway of the internet — like stars in galaxies or acquaintances misfiring in their Facebook…
While that may be a way to protect private information today, I believe there will be further innovation in this area. I, for one, am looking forward to a day where I do not have to keep track of all of my accounts and password combinations in a Word document, but instead can log in to services seamlessly because they can sense and verify I am who I say I am.