Artifacts presenting the role of technology in the world and its importance.
- New technology advances slowly and new technology is available to a select few.
- People are influenced, constrained, and motivated by technology in every stage of the design process.
- The design process results in the creation of things in the form of products, services, and systems.
- Things shape people and some of those people are are influenced, constrained, and motivated by new technology.
- New technology advances rapidly and is available to a large population.
- Ubiquitous new technology allows more people to act as designers.
- People are influenced, constrained, and motivated by technology in every stage of the design process.
- The design process results in the creation of things in the form of products, services, or systems.
- Things shape people and most of those people now design things.
This is important because I value people and want to live in a world of things that do more good than harm.
Please join us at our third annual Design for Impact Bootcamp, to be held on Saturday, Mar 31, 2012. This day-long event will introduce you to the research and design approach we use at Austin Center for Design; after taking part in the event, participants will have:
- Acquired a high level process for approaching large-scale social problems, and understand the challenges associated with these types of problems
- Experienced the research, synthesis and ideation processes as related to design for impact
- Gained empathy with a target, at-risk population
- Acquired the introductory vocabulary to speak about strategic design work, in the context of designing for impact
We are excited to welcome two new faculty members, who will be teaching class in the upcoming quarter:
Matt Franks is a Senior Interaction Designer at frog design and the co-owner of Monster Feet design consultancy. Prior to working at frog, Matt was a hybrid interaction / product designer for Target Corporation. His work ranges from mobile systems for both handsets and tablets, to entertainment experiences for TV, web, and video. In the past 4 years, he has released over 400 products and services into the market. Matt will be teaching the Design Studio class.
Jan Moorman is a design researcher for projekt202, where she is responsible for both generative and evaluative user research. Jan holds degrees in Fine Art and Computer Science. She has worked in analytical chemistry, software architecture, scientific visualization, performance support and interface design. She believes that the skill of research cannot be completely learned from textbooks and is excited about having the opportunity to mentor and coach the ac4d students. Jan will be teaching the Evaluation of Interaction Design Solutions class.
Welcome, Matt and Jan!
This quarter I created a prototype for a web app called Healthify. This application allows people to find and easily modify recipes in real-time to make them healthier. The goal of the app is to encourage individuals to try healthier recipes through a user interface that encourages experimentation and gives immediate feedback of the benefits of healthier ingredients.
I learned a lot during the creation of this web app. First, I learned the value of working through the higher level concepts of an idea before diving into the details. As a developer I have a bad habit of rushing to coding as soon as possible. However, this tends to result in creating products that are poorly thought out and have little value to the end user. Working through the higher level ideas of the app and considering the goals and needs of the user allowed me to create a prototype that fit better with what the user desires.
I also learned the value of iteration. Forcing myself through the cycle of making, evaluating, and refine allowed me to see the issues with my app earlier and work through them. If I didn’t move through this process the value of Healthify as a product would have been questionable at best.
Finally, I learned that explicitly wire framing every screen of my application saves on valuable development time. I have a bad habit of coding too quickly and then making poor interaction decisions which I need to redo later. Making every frame allows me to quickly see the issues with the app and then change them before I spent time coding.
However, there are a couple things I would do differently next time. First, I would not create my prototype in HTML. I wasted way too much time fiddling around with random bugs. Also, I realized that potential clients would not appreciate all my extra effort anyway since the end result is visually indistinct from other types of digital prototypes. Next time I will strongly consider making a clickable PDF instead since it creates the same effect for end users with significantly less development time.
Secondly, I would show my idea to more people during the development process. After my final presentation of Healthify I received a couple ideas for my app that I wish I discovered sooner in the ideation process. Next time I will try to get as much feedback as possible to improve my app’s experience.
Overall I am very excited how Healthily turned out. Through rapidly iteration I was able to create a working prototype of a product that I feel has real value to people who want to eat healthier. In the coming months I hope to build Healthify into a real product that encourages people to try baking with healthier food choices.
The answer was a yes, coming from Matt Franks and Lauren Serota in their Rapid Ideation and Prototyping class. The idea of drawing is fairly scary to me, it’s never come easy, nor has it been something I’ve enjoyed to do. I remember in the first week of my masters program in architecture one of my fellow students asked if I wanted to spend the afternoon sketching by the river. I replied with a polite, “no,” but in my head I was thinking he was crazy. Really? Spend a whole afternoon sketching? Sounded terribly boring, I much rather go for a run by the river and take a mental picture, I could draw it up quickly in CAD later anyway. I’ve avoided sketching like the plague since then.
Much to my dismay, I had to pick up a pencil and sharpie in this class – though my disdain for drawing slowly faded through the 8 weeks. I’m not sure where it happened along the way, but last week as I was doing work for another class I thought to myself, “this would be much easier to figure out if I could draw it.” As I was externalizing the problem, I caught myself and laughed, then smiled at the progress I have made. Perhaps I always have had designer-ly tendencies, but never had the tools to communicate them in a visual way before.
I have to thank Lauren and Matt for helping me to feel that I can call myself an interaction designer, because they gave me the tools to express myself as one. Not only do interaction designers facilitate the dialogue between a product, service, or system, but they are, in general, problem solvers. In this class, we each took a problem we had around the topic of food, found an opportunity to fix it, and create a web application as a result. The tools we used to solve this problem include use cases, scenarios, storyboards, process flows, wireframing, and prototyping.
The result of this process for myself is called Eat: Play, a web application for athletes that play hard and need good food to fuel their fun. This app helps find, review, and share crowd-sourced recipes that nutritionally prepare, sustain, and reward your body for a race or event. The athlete using the application can calculate nutritional needs, prepare race plans, and share recipes with friends.
I’ve posted two parts of the process we used on the path to creating a web app, wireframes and a clickable pdf. These don’t display the full functionality of the program, but focus on two different flows that a user might go through while using it – determining how many calories they need during the day of a marathon and browsing recipes to fulfill those needs. Start with the wireframes and follow the purple dots, it will give you a better idea of where you are supposed to be heading before you go through the clickable pdf.
<wireframes> <clickable pdf>
As I use the tools acquired in this class for future projects, I will be most cognizant of the rigor required to produce a cohesive product. It is important to put the work down, take a break, pick it up again, review, and revise; then repeat this process over and over again. And of equal importance in this process is the level of fidelity used in each step. Start at a low-fidelity so you can revise quickly and efficiently, which would have resulted in a more comprehensive wireframe package for myself in this case.
The last bit of advice? Pick up a pencil and don’t be afraid or ashamed of what comes of it, and do it often. I wasn’t afraid to draw when I was little, but only stopped when I became self conscious of what others would think. Instead of watching my niece and nephew color over Christmas, I think I’ll join them. You should too.
Happy Holidays! Let it snow… (a lot, please)
Hi blog readers!
We’re done with the second quarter and it was awesome. We have our big ideas from the research we did, we’ve made a ton of things in support of our initial ideas, and we’ve learned a bunch of methods for blowing out our ideas. The design idea I worked on exploding, assembling, and iterating is called Edible Rambler (previously Wild Edibles Map, and the name is still under consideration). Some of these methods included use cases, scenarios, storyboards, process flows, wireframes, prototypes, and finally the dreaded presentation of the product.
I presented Edible Rambler on Thursday evening along with delivering the wireframes and prototypes which has been the most challenging thing for me in a class for making. I can hack the production of deliverables; I’m familiar with the tools and I’m confident with the methods, but the public speaking is another ball of wax. My level of anxiety about presenting has become manageable when I’ve left myself time to organize the presentation and run through it at least once beforehand. However, NOT having left myself time for this on Thursday made me realize that I can still get through in a somewhat organized fashion with little preparation. Pushing myself to complete the materials, get in front of the whiteboard a full two hours before I present, and knowing that the whole thing won’t go pear-shaped if I haven’t memorized a script will absolutely help me with the anxiety next time. Finally.
There were a few other methods that posed a challenge for me which I’ll speak about briefly. One of these was conceptualizing the wireframes without a solid business model. I found it frustratingly difficult for me to wire-out the flow of a service that should be seamlessly integrated with it’s financial model. I burned through a lot of scrap paper mapping out the flow of the UI, which eventually helped me understand how I want the business to function. Next time however, I’ll make sure to have the Business Model Canvas done long before I’m at the wireframes stage and before I try and design the user interface. The process flow was also a learning experience for me. It was a great way to understand how to step through the use of a service through yes and no scenarios which lead you further along, terminate your experience, or more often take you off-course and loop you back around. It was an interesting way to think about system functionality and extremely useful.
So without further delay, let me introduce Edible Rambler, a free mapping app that allows you to post and share edible plants, trees, fruit in both urban and wild areas! Registration to the paid service would put you in touch with a community of private gardens and allow you to share and trade garden edibles!
Let me know what you think!
It’s the first day of Christmas break and I still can’t stop thinking about AC4D Last night was our final presentation for our Rapid Ideation and Creative Problem Solving class. See below for a summary and reflection. Enjoy!
Rapid Ideation and Creative Problem solving is basically a fancy way for describing an Introduction to Making. This course provided me with a filter and framework for the entire process of creating something that previously did not exist, which was helpful given my preexisting phobia of making. Below is a quick snapshot of the process with mini-definitions to follow. (Note: if this really excites you, you should google the terms in the diagram as I am simplifying definitions for people like me who are impatient readers :).
Use Cases: A top level view of all goals an artifact will help users accomplish. Note artifact is a fancy word for thing.
Scenarios: Stories of imaginary users and how they will interact with your artifact given specific situations, needs, and desires.
Storyboards: Sketches of the scenarios that visually (and more completely) showcase the essence of an artifact.
Process flows: A focused and oftentimes technical view of the steps that need to happen to make your artifact work.
Wireframes: Visual layout and diagram of the artifact that starts to communicate how the artifact will look and feel visually.
Prototype: A test artifact that has many of the same features as the finished product used for the purposes of communicating an idea and testing how users will interact with an artifact.
To better learn this process we came up with an idea related to our research, which we would then put through this process. My idea was Food Find, a web application that of functions like a Groupon or a deal of the day…but for FOOD!
Here is a link to an interactive prototype. Note you’ll most likely have to download it, and view using Adobe Acrobat or Adobe Reader X.
When reflecting on things that I learned about the process and my idea, Food Find, one of the first things that comes to mind is the importance of rigor. The creative process is oftentimes depicted as a single moment, much like the flip of a switch to turn on the metaphorical light bulb. This is far from reality, or if it is reality it is one small step in the creative/making process. And the subsequent steps (see chart above) can change the initial lightbulb idea completely.
This process also taught me the importance of visualizing ideas both through storyboards, wireframes, and prototypes. Oftentimes, I rely too much on my oratory ability which I think is much stronger than it actually is. But I was blown away with how ideas and concepts surrounding Food Find were much easier to grasp by others when it was visually externalized.
The next time I do this process, I am going to push my self to externalize and visualize even more. I was super impressed by my professors Matt Franks, and Lauren Serota, and some fellow students, Diana Griffin and Cheyenne Weaver’s ability to bring ideas to life through thoughtful and provocative visual design, and I definitely want to grow in that area.
Also next time, I will take more sersiously the beginning stages of the process, (writing stories and basic diagrams), which at the time seemed a little trite. The old adage you have to crawl before you run is definitely true in that one can’t design something big and complex until he or she knows the basic uses for it.
In summary, this was a great class. Many thanks to Matt and Lauren for teaching it, and I’m looking to seeing how what we learned manifests itself in 2K12.
Dentist’s Offices, The Ritz Carlton in Costa Rica, Coffee Shops, Japanese Bullet Trains, and purchasing an HP touch pad…
These were some of AC4D 2K12’s best and worst examples of a “service” which we then discussed, dissected, and diagrammed during the first few classes of our service design course taught by the man, the myth, the legend, Jon Freach (@jfreach).
Like other AC4D classes, wisdom and knowledge were not gained through lecture but primarily through reading, thinking, making, reflecting, disagreeing, drinking, then making some more. We learned from case studies and Jon’s first hand experiences with designing services such as the wayfinding system for MD Anderson Hospital in Houston, Texas.
We also used insights gained from our research to design a service that would meet the needs of a vulnerable population of people. Ultimately, Ben Franck and I came up with the blueprint of a service, We Cook, we are going to try and bring to market next semester. See below for a description.
In short. We Cook is a service that facilitates groups of people cooking a week’s worth of food together for an affordable price. Below is a short case study of a potential user.
She hears about We Cook from a friend who tells her that it is an inexpensive way to get a week’s worth of healthy home cooked food.
While there are many design challenges associated with this service, we are super excited at the potential to leverage the economics of food purchased in bulk to change people’s behavior surrounding food.