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.
 
 

Road Sage, a project at Berkeley for which I led design and needs analysis, won second place among 18 contenders in my department's 2004 final project competition.

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.
 

 
CarlHiaasen.com is best-selling novelist Carl Hiaasen's official Web site. Several years ago I redesigned the site and I continue to maintain it for Mr. Hiaasen.

 


Scient work: For nearly two years I developed interfaces and site architecture for several of Scient's most important clients, including a Fortune 100 financial services corporation and a Fortune 500 biotech firm. I was based in San Francisco's San Francisco office, but I also worked for Scient in Chicago and New York.

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):

 - click to zoom in -

Unified Specifications: Each Unified Specification verbally describes a use case scenario involving a critical group of functions that the software will support. It outlines the actions that the user takes in carrying out the scenario, and the responses that the system provides. The focus here is on the primary (most-often followed) flow, but alternate flows branching off from decision points are also described. Further terminology links the document with its function set, as defined within another document -- the project Scope Map -- which lists and prioritizes all functions to be included in the product.

The Unified Specifications define, at a high level and with contributions and signoff from all major stakeholders, the system's most critical functions. The Unified Specifications document everyone's understanding of the problems at hand and how the final product will solve them.

Interdisciplinary teams, with members representing all stakeholders, gathered in conferences to flesh out Unified Specifications for all functional groupings within the Scope Map. As we initially built these documents I advocated the users based on the primary user research and based on general usability heuristics. In later iterations we made adjustments based on new criteria, including results from usability tests of the Wireframe UI Prototype.

 - click to zoom in - An early User Interface Flow: In creating the UI Flows, I sketched out page-by-page functionality and page elements for the first time. They show a first version of much of the information that will appear in the prototype, but they're much quicker to build than the prototype and they show whole flows at a glance, which allows high-level verification with stakeholders in much less time than a prototype would require at this stage.

This UI Flow illustrates a patient's experience while registering with the system. Please note: the "navigation goes here" was a placeholder for top-level navigation elements that were under development by the information architects. "Disclaimer" wording was being developed by legal advisors and by the content analyst.

 - click to zoom in - A later User Interface Flow: This diagrams a patient or caregiver entering one of six types of medical log entries. Universal navigation and other extraneous information has been dropped to speed the creation process.


 - click to zoom in -
Annotated Page Schematics document the individual pages of the Wireframe UI Prototype in detail.

Each Annotated Page Schematic includes an image of a single screen within the Wireframe Prototype, with descriptions of each element of that page.

Annotated Page Schematics also explain which function group the screen belongs to, where it fits into the tasks, where specifically it can be found in the Wireframe Prototype, etc.





In 1996, after my success at the Bradenton Herald (see below), that newspaper's parent corporation transferred me to its new digital research-and-development headquarters in San Jose, California. I was one of the first staffers there.

My work focused on user interface design and Web production. My projects here included:

  • Clarion, a dynamic content system that provided customized content for viewers. Clarion was used as a foundation to rebuild and power the Web sites throughout the Knight Ridder network of more than 30 newspapers.
  • JobHunter, a suite of job search and career information services that was rolled out in dozens of markets across the United States.
  • NewsHound, a customized news search and retrieval service
  • HomeHunter, a package of content and tools for home buyers and sellers
  • Sports columnist Mitch Albom's online home (at Inkling.com, Knight Ridder's national online magazine).

 

 

"What you did in Bradenton was heroic." - Chris Jennewein, then Vice President, Technology & Operations, Knight Ridder New Media.

 


BHIPBradenton 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.