Developing a web application to visualize the impact of public health programs. The application is built with Ruby on Rails and utilizes Twitter Bootstrap. It's been enjoyable working with these frameworks, as it definitely enabled an agile development process.
I recently completed some design work for the folks at Exec, a service for on-demand labor. In this project, I focused on the brand identity and designed a splash page that would quickly communicate the value proposition. I used the frequently asked questions and common worry points as guidelines in crafting the story of the splash page. I really enjoyed this project, definitely looking forward to more work with a focus on brand identity and effective communication.
This mobile tolling application effectively replaces the transponders found in commuter vehicles, allowing for seamless tollway fare payment. As the user experience designer of this iOS application, I lead the interface design and Objective-C development. Currently the application is being customized for a pilot with the Golden Gate Bridge.
Chicago Founders is a Q&A community for Chicago entrepreneurs. The forum was designed to help support the budding entrepreneurial community in Chicago. Forum members are able to ask and answer questions and use the forum as a platform to develop the Chicago startup community. Members are also able to chat in real-time, promoting instant discussion and networking opportunities. Chicago Founders is a deployment of OSQA (Open Source Question Answer), a python web application built on the django framework. You can visit the forum at chicagofounders.com
Update: Chicago Founders has been acquired by Built In Chicago! The forum will continue to support the Chicago startup community as Built In Chicago Answers. Chicago is rapidly becoming a startup hub and it is with great pleasure that I can collaborate with Built In Chicago to ensure that it does. The Chicago Founders brand will continue to live on in a new development that will surely be a catalyst in Chicago's development as a startup hub.
The Google Cafes project is a design exercise to create a web application that allows Googlers to easily decide where to eat on campus. Users are able to browse menu items, gauge cafe traffic and make reservations, enabling Googlers to find the cafe that fits their dietary and scheduling needs.
Design Brief
Google has several cafes around the sprawling Mountain View campus, each with different menus and seating capacity.
What's needed is a system that allows employees to select a cafe based on food choices (vegetarian, kosher, allergies, caloric intake), traffic in the cafe (including reserved tables for groups and visitors), other considerations that you may think of such as guest chefs or events.
Assume any information about the cafes will be available to you through webcams, menu breakdown with ingredients, reservations.
Given three months, what process would you use to approach this design problem?
Break this down into a schedule with an overview of activities for each phase.
Produce a low-fidelity overview of the product or feature (wireframes or sketches are fine) Produce a high-fidelity mock & specifications for one widget or interaction.
Design Process
I began the design exercise by defining the key functionality requirements of the web application. Google Cafes had to allow its users to easily select a cafe based on the cafe location and menu. For the cafe locations, I thought the users would be most interested in their proximity to the cafe and the traffic in the cafe. In regards to the menu items, I concluded that the users would be most interested in seeing an image of the menu item, a description, nutritional information, and any information pertaining dietary restrictions.
Having defined a high level overview of the functionality requirements, I moved on to sketching out some design ideas. I realized that the functionality required from finding a suitable cafe location was similar to the functionality of Google Maps. Likewise, the functionality required from browsing the menu items was similar to Google Search. As a big fan of the recent Google redesign, I also wanted my Google Cafes design to easily integrate into the Google portfolio of web applications.
I partitioned the Google Cafes design into two areas. The left hand side would be a navigational sidebar that would allow the users to navigate through the Google cafe locations. The user is able to view the cafe locations on a map of the Google campus. The web application automatically obtains the users current location or the user can manually set their location through drag and drop of the current location icon. Users are able sort cafe locations based on distance and cafe traffic, allowing them to easily gauge their proximity and the wait time at each of the cafes. Users are also able to toggle to webcam view to observe the cafes in realtime. Finally users are able to make a reservation once they have decided on a cafe location.
The right hand side would be the section of the web application for searching and browsing through the menu items. The user is able to search for menu items by name, ingredients, and descriptive tags such as "italian food" or "gluten-free". Searches are localized to the cafe that was selected on the left hand navigation bar. The user can also select "Browse All Cafes" in order to view the menus or search amidst all of the cafes. The search results would then be displayed and sorted by relevance or other sorting filters such as "health rating" or "food category". Menu items are represented by an image of the food item, a title, a description of the ingredients, and descriptive tags. The tags contain information such as health rating (green, orange, red), food category, dietary restriction, and other useful information. A blank search would just allow the user to browse the entire cafe menu without any targeted search.
After deciding on this design, I took my sketches and converted them into a Photoshop mockup. Since I wanted Google Cafes to integrate with the Google portfolio, I used the styling characteristics and web elements from Google's current web application portfolio and created a mockup. The next section gives a visual overview of the design.
Concept Overview
In this screenshot the user has selected American Table on the left sidebar. She is searching for salad, pizza and spinach. She has also indicated that she has peanut allergies. The delicious results have also been displayed, allowing the user to browse her preferred menu choices at American Table. Once the user has envisioned a great dining experience, she makes the decision to make a reservation or just shows up at American Table if the webcam view didn't seem too crowded.
Process & Interaction Overview
One of the most interesting aspects of Google Cafes is the search functionality. In many respects the functionality would be quite similar to a normal Google search. However since we are searching menu items, users will most likely be interested in multiple menu categories or search keywords. Therefore I went with a tag search functionality that would allow users to fine tune their searches. For my high fidelity mockup of an interaction I chose to show the process of using this search functionality.
In this use case our persona is Cameron. She is looking to get an early dinner and has a general idea of what she wants to eat.
1. Cameron logs onto Google Cafes and sees that the application has determined her location and sorted the cafes by distance to her. She clicks on American Table because it is the closest to her and she's feeling patriotic.
2. She sees that the traffic status is busy so she toggles to webcam view to check out the real time status. It does seem pretty packed, so she mentally notes to make a reservation if she decides on American Table.
3. Cameron has an idea of what she's in the mood for. She would like to eat salad, pizza, or any dish with spinach. Cameron really likes spinach for some reason. So she types in salad, presses enter and does the same for pizza and spinach.
4. The tags for Salad, Pizza and Spinach are displayed for Cameron. But she realizes she has one more request for Google Cafes.
5. Cameron loves Spinach, but she hates peanuts with a passion. She's actually quite allergic to peanuts. So she clicks on dietary needs. She sees that there are checkbox options to indicate halal, kosher, vegan, and vegetarian preferences.
6. Cameron scrolls down to food restrictions and sees that users can select restrictions on dairy, gluten, peanut, seafood, and sugar.
7. She checks the box next to Peanut and sees the Peanut Allergy tag appear on the right side of the search box.
8. Cameron clicks on the search button and sees her menu search results. She's trying to eat healthy, so she sorts the results by health rating. She's satisfied with her available choices and then makes a reservation.
Given 3 months to design and build Google Cafes, the following depicts how I would structure the roadmap. Overall, a user-centered design and agile development process would influence the roadmap. There would be an emphasis on iterative design and testing that is focused on the end user. I would structure the project like an entrepreneurial organization within Google, focusing on product and customer development.
Week One & Two
• Create the 3 month roadmap.
• Gather the team and set the budget.
• Determine if the project will be funded or based on 20% time.
• Set up a blog to generate awareness and announce progress.
• Conduct extensive preliminary design research by talking to Googlers about the idea, interviewing them about their meal decision process and getting initial suggestions and expectations of a useful cafes application.
• Conduct similar design research studies with the cafe management and Google executives
• Observe Googlers on their lunch or dinner process from start to finish, focusing on contextual inquiry to identify the key drivers and motivations of their actions.
• Digest information and organize the key insights by creating user personas and user scenarios.
• Brainstorm on the minimal viable feature set and specifications.
Week Three & Four
• Create low-fidelity sketches and wireframes (sketching & balsamiq mockups).
• Paper prototyping with target end users and conduct feature set card sorting.
• Set up the code repository and wiki & bug tracker.
• Begin coding the minimal viable product, just the front-end prototype in the beginning to test out the interactions.
• Analyze and synthesize the feedback from the low fidelity prototypes.
• Group feedback into high level categories, find key insights and funnel information back into code development.
• Prioritize feature implementation based on feedback.
• Finish the minimal viable feature set prototype by the end of week four.
• Deploy the prototype to a URL.
Week Five & Six
• Generate initial cafe traffic ratings based on reservations in the system.
• Begin the process to populate the cafe and menu database.
• Implement a reservation system that can work in parallel and in sync with the legacy reservation system.
• Add the Google feedback plugin to begin getting feedback online.
• Share the URL to our target users through an announcement on our blog.
• Determine metrics to measure success on Acquisition, Activation and Retention.
• Start measuring success and begin A/B testing.
Begin the post-prototype iteration cycle of agile development
• Analyze- Observe users and test the application.
• Synthesize- Measure success metrics and digest user feedback.
• Design- Reprioritize features and bugs to be fixed.
• Execute- Make changes, test and deploy.
Week Seven & Eight
• FInish populating the database with all of the cafes and menus.
• Analyze the menu for dietary restrictions and other descriptive tags.
• Begin the process to design a system to better judge traffic and wait time (initial ideas include weight sensor mats in the cafe lines, using NFC readers or data analysis on Google ID swipes).
• Continue to conduct user testing on how our application is being used.
• Analyze online feedback and conduct more observations on end users, targeting key questions using contextual inquiry.
Week Nine & Ten
• Install web cams in all of the Google cafes that are missing webcams.
• Install the necessary hardware to better gauge traffic and wait time (weigh sensor mats, NFC readers, ID scanners, etc) .
• Fully transfer the reservation functionality from the current legacy reservation system to Google Cafes.
• Perform performance tests and optimize results.
• Continue with the iteration cycle defined in the Week Four & Five phase.
Week Eleven & Twelve
• Implement Google instant search functionality.
• Start experimenting beyond the functionality requirements. Use the feedback from users as a guide, as well as conduct brainstorming sessions frequently.
• Design integration with Google Plus. Specifically around the areas of suggesting menu items or special events to friends and collaborating to find a reservation that is of mutual fit.
• Design functionality in the reservation system to reserve a table for Googlers that want to share a meal with strangers and network within Google. The feature could be called “I’m feeling friendly”, a play on the “I’m feeling lucky” button.
• Convince Larry Page, Sergey Brin and Eric Schmidt to have dinner with Googlers using the “I’m feeling friendly” functionality staggered during three days of launch week.
• Advertise the event and officially launch Google Cafes into Beta that week.
• Develop the roadmap to transition the project for the long term.
• Likewise, continue with the defined design and development iteration cycle.
Download
It was a pleasure to design Google Cafes! You can find a pdf of the screenshots here.
The Cloud Enterprise Marketplace is an application store that showcases the featured cloud offerings of a top technology consulting firm. As the user experience architect of this project, I defined the overall user experience and managed the global workflows of development teams in the United States and India.
The Cloud Management Application enables users to monitor anad manage their cloud instances in real-time. Users can organize their instances based on business units and project structure, facilitating more efficient project management. As user experience architect of this project, I defined the overall user experience and lead front-end development.
I have been a long time fan of Ferrari. Their cars are a pure representation of form following function. I wanted to capture the design language of Ferrari and translate that to the design of a sound system.
I primarily focused my study of the Ferrari design language through analyzing the Ferrari 599 GTB.
Much of the distinct styling found on the 599 GTB can be attributed to its need for aerodynamics and venting. Likewise, a sound system would also need proper venting and airflow to generate the best acoustic properties. This would be prove to be a useful analogy in bringing Ferrari design traits to my speaker design.
After multiple iterations of design sketches, I focused on this concept:
I was primarily inspired by the side vent of the 599 GTB. Like the Ferrari, my speaker would also have aerodynamic venting for the tweeter and subwoofer.
The final prototype was created using a single block of high density modeling foam. It was a tedious process, as the prototype was crafted utilizing sanding blocks and hand tools, but it was certainly a great learning experience. The model was then primed and painted Ferrari red, featuring the famous Pracing Pony emblem. Overall, I am quite pleased with the final result.
The Miller Electric project was a redesign of an entire lineup of welding systems. This project was a great experience as it showed the effectiveness of user-centered design. Our project team had no previous experience with welding, however through design research and a focus on the end user we were able to design an intuitive welding system.
The original Miller welding system design was actually well received by professionals in the field. However, for new users it was not intuitive and required manual reference. Many of the features were nested in hierarchies and required the user to key in specific input combinations to access hidden features. The overall system did not emphasize the design principles of feedback and forgiveness.
Given that welding was an esoteric topic for our project team, we immersed ourselves in the trade, taking welding lessons and repeatedly venturing into the field to better understand the brand and the community. We observed welders in the field, conducted user testing on our wireframes, categorized features through card sorting, and continued to iterate towards our design. Our final design is represented by an intuitive reorganization and consolidation of the features and controls.
Snocom was a project to develop a device for snow sports enthusiasts that would allow for readily accessible communication.
As an avid snowboarder, I found that it was quite difficult to communicate while at mountain ski resorts. In order to further develop this idea, we conducted ethnographic research and analyzed the marketplace. We found that often cell phones had unreliable reception on the mountain and the nature of snow sports apparel caused the use of conventional communication devices to become cumbersome. From a use case perspective, our users were mainly interested in contacting their ski groups in order to coordinate plans and stay together. We also found that many users enjoyed listening to music while skiing or snowboarding. From our research of snow sports enthusiasts, we developed the idea of Snocom.
Snocom is an easy to use communications device for snow sports enthusiasts. The concept is a rugged case design that allows the user to enjoy music on the mountain and communicate easily through radio transmission.
The Snocom hardware can be separated into 3 units: case, audio drivers, and microphone. The case houses and protects the user’s media device. It is designed to be compatible with the iPhone and iPod or any Bluetooth compatible media player. The audio drivers can either be clipped onto goggles or dropped into helmets with industry standard audio earflaps. The microphone is clipped and locked on the jacket collar.
Snocom controls were designed to be rugged and easily handled with gloves. Within the case are large buttons that set the radio broadcast channel. Since Snocom works with the same radio frequencies found on traditional 2-way radio, it is fully compatible with all 2-way radio devices. To communicate, the user simply presses down on the rugged control wheel and speaks into the microphone. Music is then automatically paused and resumed during radio communication. Turning the spring-loaded control wheel left or right decreases or increases the audio driver volume. Much like the crown of a watch, when the control wheel is popped out, a turn of the wheel left or right navigates to the previous or next track and a press down on the control wheel pauses and resumes the music. Overall Snocom is a device that improves the quality and enjoyment of snow sport experiences.
Memorybeat was a project that allowed me to get familiar with the Arduino prototyping platform. It's a very useful prototyping tool, as it's amazing how much is possible just with a single open source microcontroller. Memorybeat is an adaption of the popular toy Simon. Basically Simon gives a random color/sound sequence and the player has to mimic it. My vision for Memorybeat was a drum set adaption of the popular 80's toy. Here's a prototype of the concept.
