Pattern Interview: Chris Tighe-Ford
Please tell me your professional role and anything else about yourself and your background you'd like to share.
My colleague, Chas Linn and I founded Model Interaction Ltd a little over two years ago. We’ve both worked within the interaction design industry for a decade or so and met when I joined Epic Group PLC (Europe’s largest eLearning company) as Lead Design (Chas was CTO); we worked on a number of projects, including the Barclays University (bu) and a global Knowledge Management network for LloydsTSB. We shared a common view of design and both believed that research underpinned any serious design activity. That can seem a rare shared interest, so - in a fit of enthusiasm - we formed our own company. How did you first discover the concept of patterns and pattern languages? I think it was probably in about 2000 - at the time I was spending a lot of time reading IA sites, newsletters and mailing lists. One of the lists I was on mentioned Alexander’s patterns method and it struck a chord. A friend of mine is an architect and I followed up the idea with him. I first used patterns ‘in anger’ when I was drafted into the UK’s eUniversity project. The design phase wasn’t progressing particularly well: the system was extremely broad and detailed and the ‘brute force’ method of design (wireframing each and every screen and recording each instance of every user interaction) had left the team buried under reams of documentation that few people had read and fewer still understood. Along with Chas and two colleagues - Dean Wilson and Jessica Jebari - we decided to try a patterns-led approach to the system design. Slightly frustratingly, the project was canned before we could complete our new design phase. By that time, we’d created a dozen or so ‘mature’ patterns and had increased our understanding of how patterns could solve the common problems of quality, consistency and efficiency in large system design. What do you see as the primary benefit or purpose for patterns? Aside from the obvious benefits of quality and consistency, I think there are probably three areas in which benefit can be accrued by using patterns: For the designer, patterns offer a great way of recording best practice and - through use - provide a great efficiency in the design process. This efficiency can manifest itself in reduced design and development costs, or by freeing the designer to spend more time focusing on the wider solution - what we'd call the design model and design behaviours. Patterns can stop us re-inventing the wheel with every new project. For individual projects, patterns allow us to approach the design of larger systems in a consistent, reproducible manner. It's been my experience that a design process that works for a 100 page site will fail - often catastrophically - when applied to a larger web system. Patterns can act as one of the supporting struts of a successful project. Patterns also allow us to create very rapid functional prototypes which can be a wonderful method of communicating intent to a client in a manner which can be experienced, understood and confidently signed-off. Finally, patterns provide agencies and organisations with the ability to capture best practice design in a communicable format. Design teams in agencies are (you would hope!) populated with bright, keen and able people, all of whom are learning about the field in which they work. Capturing and sharing this knowledge is a key concern for businesses and a well-regulated pattern library can act as a good starting point for this kind of knowledge sharing. And the purpose of design patterns? I think that by sharing patterns (and publicising their existence!) we can improve the quality of our general interactions online. If other designers would take (for example) Martin Welie’s registration and log-in patterns, we’d see an immediate improvement in the usability and security of the sites they design. Grumpy old man that I am, I'm continually frustrated by the over-complication of the UI that is present in so many public web services. I'd hope that a wider adoption of patterns might go some way to addressing this, and - in turn - save my sanity. What drawbacks do you see? The drawbacks fall into two main camps, I think: the difficulty of selling the concept to a team of designers and the cost of developing and maintaining a decent pattern library. The former was a problem we encountered at Epic: a number of designers felt that the use of a patterns library would impact their creativity. This concern is understandable, but I felt at the time (and still feel) that using a pattern library for common, repeated interactions gives the designer more time to focus on the wider solution for the project (the design model and behaviours, mentioned previously) - which for me is the most interesting part of the design process. The problem of cost is a big issue for companies our our size: I guess Yahoo don’t have many problems funding your team but we have a slightly smaller budget :) . I'm convinced that there is a cost saving over time, but the initial investment is not insignificant. Ongoing maintenance of a patterns library is also an issue. It's probably important to sound a note of caution about patterns here: although most patterns are described in simple, clear language, it's important that we don't forget that patterns are expert tools. As an example, anyone can download IBM's heuristic checklist but it takes a usability expert to employ them profitably. Patterns might tell you how an interaction should be presented, but it can never tell when it should be used! Do you have any preferences between the different styles of writing patterns? Personally, I prefer that patterns don’t make any reference to the ‘presentational’ aspect of design - having said that, in our List pattern, for example, we’ve specified that alternate items should be differentiated by alternating, shaded lines, so I guess I’m no purist… I also think the patterns we produce tend to be quite prescriptive - I think that might be a broad split between the public patterns libraries that are out there - the prescriptive patterns vs the descriptive patterns. Do you have any opinions about the best ways to organize patterns into pattern languages? I’m in agreement with Patrick (Patrick Stapleton, Oracle): I think that there are a lot of benefits in a universal method of organising patterns. One of the strengths of the patterns approach is the possibility of adding to an existing, public library over time - I think some sort of loose taxonomy would make this job easier in the future. I'm of the view that no-one ever complained about having too much metadata - let's define a PLML and see what kind of classifications arise from it!