Category Archives: Innovation

d.school (“Hasso Plattner Institute of Design”) at Stanford University

Back in fall 05 I first heard about the newly funded/founded “Hasso Plattner Institute of Design” at Stanford University[GP:dschool]. SAP’s Hasso Plattner had just recently given $35m to the university to set it up. I got somewhat excited – this looked extremely interesting. The “Hasso Plattner Institute of Design” (aka “d.school”) is an interdiciplinary design department with the aim of educating future design thinkers and innovators (you don’t say “inventors” anymore). Before Christmas I had been trying to arrange an appointment with David Kelley, a professor for design and one of the founders of this institute (and one of the founders of IDEO as well). I didn’t hear anything for quite some time, but then (just a week ago) I got an email from his assistent (thanks Charlotte!), and just two days ago she asked me, why don’t you just attend the first session of the new class. You bet I just couldn’t NOT go there 🙂

D.School at Stanford

So we went to see the Campus, and later I went to the kick-off class. There were some 60 students and 15 staff (what a dream proportion!). Within one our, we fast-forwarded through the entire design process for a wallet (a very personal item) from requirements analysis to physical prototypes. Later I had the opportunity of talking to Mr Kelley – very very fascinating, but (unfortunately) no post-graduate offerings I could use. Too bad.

Here’s some background information I got:

The Hasso Plattner Institute of Design at Stanford (we call it the ?d.school?) is a new interdisciplinary teaching program about design thinking. Made possible by a generous gift from Hasso Plattner, it is intended to advance multidisciplinary innovation. We are in our first full year of operation, in startup mode. We plan to grow and change the program rapidly in the next few years.

People: We see the d.school as bringing together a wide variety of people, not just from different disciplines, but from different backgrounds. We will augment regular faculty and staff with active participation by people from industry, at all levels of teaching and participation. As things develop, we will provide a place for this broad community to get to know each other.

Degrees: There is no official d.school degree. Because we are inherently interdisciplinary, we don?t expect to grant separate ?design? degrees, but to explore ways to include a design designation as part of departmental degrees.

Relation to other Programs: The d.school is closely affiliated with, but not the same as, the Product Design program in the Mechanical Engineering Department. Many of the d.school students will be from that program, but our goal is to have students from other related programs, such as the HCI program in the CS Masters, the Bio-design program, GSB students, the LDT program in the ED School, and others.

Admissions: No students are admitted to the d.school yet. Students participating in the activities are regularly enrolled degree students in any department at Stanford. We look for people to bring their interdisciplinary expertise to the projects, so our focus is on graduate students, primarily masters.

Post-Graduate Opportunities: Each year we have a staff of paid fellows who have graduated from a design or related program and who help to create and guide the projects and courses. We will announce later in the year how to apply for this position in future years.

Prototype-based xApps Design Process

I've recently come across an article I wrote back in October 2003 for SAP Design Guild. The text deals with the xApps design approach we were following then; driving product definition and design through rapid prototyping. In the article I describe the process we were using – quite successfully, I'm proud to say. From the introduction:

In the following text, I describe the prototype-based design methodology used by SAP's xApps Design Group. I explain the prototype development life cycle, discuss the advantages and disadvantages of different prototypes and prototyping materials, and illustrate how the prototype approach fits into SAP's xApps software development life cycle.

CHI 2004 – April 24-29, Vienna, Austria

This April I – again – attended the world's biggest HCI conference – the CHI 2004 "Connect" conference (Computer-Human Interaction), which took place in Vienna, Austria[GP:Wien]. Two years ago, I was so lucky as to attend my first CHI in Minneapoli, Minnesota in 2002. In 2002 I came back quite disappointed; although there were lots of high-quality contributions, I couldn't really follow the discussions (which were often very much focused on tiny details and did not really have to do with Interaction Design as a craft). Moreover, I found the way people treated each other not too nice, and to me it felt strange that everyone introduced themselves with "Name, Insitution". Back then I was also disappointed by my former personal guru Don Noman – on the panel I attended he did not feel as radiant and thought-provoking as in his books. My overall impression of this year's CHI (as compared to 2002's) was: less academic stuff, more real-life application of research results.

There were fascinating panels (e.g., "Video Visions of the Future: A Critical Review" with Bruce "Tog" Tognazzini and others – Bruce alone was worth attending the panel!), challenging SIGs (special interest groups) such as Karen Holtzblatt's "Techniques for Designing Mobile Applications with Customer Data" (i.e., how to modify traditional Contextual Design methods to be useful in mobile situations), and intriguing demo sessions (e.g., "Visualizing information"). Some of the things demoed at the conference are available for download as well, e.g. MIT's "Haystack" prototype for information (contact, document, e-mail) management. I attended some very intersting stuff on mobile technology, among this an interesting panel with mobile user experience leaders (from Vodafone, Nokia, Ericsson etc.).

CHI 2004 Logo

Of course, there were some weaker points, too – e.g. the SIG on "Evaluating Interactive Information Retrieval Systems" (which was really a SIG for Information Retrieval researchers). These things didn't add up to much disappointment, though – there was so much to see, and somehow it worked out for me to find something interesting and worthwhile in nearly every slot, with hardly any conflicts of schedule. Moreover, I enjoyed meeting old acquaintances and getting to know new experts. Organization was ok, too (although the convention center building did have some issues as far as signage is concerned – you could end up running in circles). The website and the conference proceedings book left something to be desired (e.g., there were no links between abstracts and sessions, so you had to flip through the book a lot), but … the CDs are great, offering all the papers as PDFs (and some of the videos are there, too!).

One personal cause of delight as a User Experience and "Joy of Use" aficionado was: if the number of Apple PowerBooks to be sighted there were in any way predictive of the overall number of Macs in the computing world, the Mac's market share would be somewhere around 30% 🙂

Hierarchies: Categories vs. Vectors

I just updated an older (2001) article of mine on SAP Design Guild, dealing with a topic I care about: the ubiquitous hierarchies used to structure information, and why they tend to fail in lots of cases. Computers have made them so seemingly indispensable (think Windows Explorer, think Mac OS Finder, think about every application you can think of), and yet in most cases that's just because today's development tools make it so much easier for developers to create hierarchies than to implement some different, more innovative, maybe more adequate approach. From the introduction:

Human beings are limited in many ways. Beside others, one limitation lies within the amount of information they can process or hold in working memory for a time given. That’s where Miller’s famous "seven plus/minus two" rule comes from – you can only have up to nine chunks of unrelated information readily accessible in short term memory. (You’ve probably already heard people telling you, "Don’t put more than seven items on a PowerPoint slide", or "Don’t build your menu structures more than seven items wide". While it’s certainly a valid recommendation to restrict yourself and not to overload your slides, Miller’s rule has been misunderstood quite often: Miller states people have great difficulty keeping more than seven or nine unrelated elements in mind. If they try to concentrate on more, access performance decreases rapidly. This doesn’t mean you cannot work with more than nine elements – if you find a way to organize those elements or to find a relation between them, it’s easy to keep lots of items readily accessible. See Don Norman’s excellent books on this subject.)