|
|
|
Work Samples: General Design and Project Management eBay Gift Registry turns the registry concept inside out. Our registries are built around people and the gifts they want; traditional registries are built around stores. In North America, couples who set up wedding registries typically do so at a single favorite store. Many couples complain about this -- the choice of gifts is limited to those available through the "host" retailer, and gift buyers can't easily shop around to find the best prices and shipping options. Some couples register with two or more stores -- they face the hassle of registering repeatedly and their wedding guests face the complexity of multiple stores and lists. We designed eBay Gift Registry to remove these limitations. An eBay Gift Registry isn't anchored to a store -- it belongs to the soon-to-be newlyweds, and it points to many sellers of the chosen gifts. The list of sources for each gift changes based on prices, shipping distances, etc. The system shows buyers the best sources on the fly. It helps couples build and track their registries without pointlessly constraining their choices. It turns almost every bricks-and-mortar retailer in the world into a showroom of items the couple can choose from. It uses eBay's technology and data to work with new items sold by retailers at set prices; it doesn't address used goods sold at auction. In addition to my key contributions to early product ideation, I managed needs analysis and interaction design for our team, which included two engineers from Berkeley's Electrical Engineering and Computer Science Department and two MBA students from the Haas School of Business. With the help of newlyweds-to-be, recent newlyweds, and family and friends of recent newlyweds, we iteratively designed a wireframe prototype and a draft business plan. We created this for our Fall 2004 New Product Development class and it hasn't been launched as a full service. From a UI and needs analysis perspective, I found this particularly intriguing and challenging because the couples we dealt with often expressed the desire to work together on their registries, sometimes simultaneously at the same computer, and sometimes as a back-and-forth, almost conversational process, as each person finds a few minutes to participate (suggesting new items and commenting on the other person's suggestions, for instance). Family members and friends also often form an important part of the wedding process and act as important advisors to the couple. We needed to learn a lot about these types of people and the roles they play before we could intelligently design a wedding registry system. Just as I learned valuable lessons about the business side of the product and about technical backend considerations from my MBA and engineer teammates, I taught the rest of the team how extremely important it is to think beyond the one-to-one user-to-machine paradigm, to view the application as a small mediating portion of a much larger system of social relationships and interactions among many people, and to value needs analysis and interface design as critical elements of a successful new product development process. ![]() In 2004, the online driving-directions services all focused on telling people the shortest route between points A and B, and on describing that via detailed turn-by-turn directions. That's great for a tourist visiting a place for the first time, particularly during times when heavy traffic is not an issue. But what about commuters and other people who are familiar with an area (and therefore don't need extremely detailed directions) but want to know the fastest route between points at a specific time? Road Sage considers live and historical traffic data to choose, rank and present routes, and to estimate travel times. It uses data logged from highway sensors operated by California's Department of Transportation to forecast traffic between given starting and ending points, and to suggest the best route at a given time in the future. It also shows live traffic along a given route. In 2004 a couple of Web sites provided traffic visualizations based on this traffic data, but they presented it at an extremely low level of granularity. A user could glance at these images to get a vague idea of how bad traffic was throughout the Bay Area, but nothing was available that tailored this information to a user's individual routes. In 2005 Yahoo! improved this state of affairs and now offers visual traffic cues with its driving directions. But still, as of late 2006, I know of no service online that actively suggests alternative routes based on traffic data. At certain times of day, traffic can render a route recommended by Yahoo! or Google or MapQuest one of the slowest possible routes between two points. Sometimes, road construction can render these suggested routes impossible. Road Sage combines real-time traffic data, traffic forecasts based on historical data, map visualizations and routing services to provide users with a new service that suggests what truly are the best routes and that also allows users to visually explore alternative routes and alternative travel times. My three Road Sage teammates were second-year Masters students in my department. Although I was the only first-year teammate, my colleagues asked me to be design manager because of the years of professional UI design experience before I had garnered before Berkeley. Mikhail Avrekh, John Han and Lauren Wilkinson (all now graduated) came up with the core Road Sage idea and worked hard for much of the year to build it out. We all moved on to other projects, so Road Sage has been shelved for now. But imagine weighting the historic traffic data with historic weather records and with the latest weather forecasts -- in this way we could more accurately predict future traffic and provide more accurate route suggestions. For regions that include sports stadiums, we could weight the traffic data on game days based on past traffic changes that occured on previous game days. Plenty more can be done here to provide increasingly accurate, contextually-relevant traffic forecasts and route recommendations, all of which can be built on top of the core Road Sage platform.
![]() My work included development of functional site prototypes, user interface flows, page schematics, use-case scenarios, and HTML wireframe prototypes. Examples of deliverables that I created and helped create at Scient (client names and other identifying information has been blacked out where required by nondisclosure agreements):
My work focused on user interface design and Web production. My projects here included:
"What you did in Bradenton was heroic." - Chris Jennewein, then Vice President, Technology & Operations, Knight Ridder New Media.
Bradenton Herald Internet Plus: My earliest experiences professionally building Web services took place in the newsroom at The Bradenton Herald, a daily newspaper on Florida's west coast. I started as a reporter, and by late 1995 my Internet business column was published not only in the Bradenton Herald, but in newspapers across the United States. I saw a bright future online and I lobbied my supervisors for the time and money needed to create a Web companion to the Bradenton Herald. When parent corporation Knight Ridder asked the paper to launch a site and a local dialup Internet access business, I spearheaded the project. In October 1995 we launched. Our budget didn't allow for a second site staffer, so I handled BHIP while filing regular articles and columns for the Bradenton Herald. I quickly learned to spread my enthusiasm about the project so I could win over photographers, reporters, ad staffers and information systems workers to help build BHIP. I spent most of my time training and evangelizing the paper's staff and members of the local community. I taught reporters, ad representatives and managers how the Web could make their jobs easier. I focused on keeping in touch with the users -- this was the most important element in our success. I ran classes and seminars that covered everything from installing dialup software to building a Web site. I visited customers in the field to observe how they used the Internet, to learn what new features they might use, and to test the site's ease of use and simplicity. I also fielded hundreds of customer calls and e-mails every week. After my successes here, the Herald's parent company, Knight Ridder, transferred me to their new digital research-and-development institution in San Jose, California: the Knight Ridder New Media Center. |
|||||||