Boxes and Arrows: Comments by Anthony Colfelt

Anthony Colfelt — Fri, 07 Jan 2011 19:41:08 GMT

“Postrel points out that “’form follows emotion’ has supplanted ‘form follows function’.” How else do you explain the success of the iMac, Volkswagen Beetle, and the Michael Graves Toaster at Target?”

Sorry, this is just rubbish. Of course form still follows function. If the iMac, Volkswagen Beetle etc didn’t function exceptionally well, they’d have been a flop.

The notion that people value aesthetics more now than they did then is a misnoma. People can afford aesthetics now, where before this was a luxury. As the population becomes more affluent and companies cotton on to the fact that people have always wanted aesthetics, goods become cheaper and more aesthetic.

People in poorer countries (or westerners earlier this century) couldn’t care less about aesthetics. If something works, and they can afford it, then that’s enough for them. If aesthetic goods were cheap enough, they’d have those instead, because the desire for beauty and individuality is something that runs deeper than trend. It roots in the way humans value themselves. This isn’t transient, in my opinion.

Anthony Colfelt — Fri, 07 Jan 2011 19:41:08 GMT

Todd > I don’t know how common it is to expect interaction designers to code. As a general rule, I think they don’t at the moment. Perhaps the industry will trend that way, but I don’t know. I’m trying to write for the now, however.
Christian > Stay tuned for part II. That’s when we talk about personality traits…
Patrick > Thanks for catching that… oops!
Alexander > This isn’t supposed to suggest you find one person that can do all these things, but rather that these are the skills that are out there. When hiring, you need to analyse what you need before choosing a candidate with some or one of these. The next part will clarify this point.

Anthony Colfelt — Fri, 30 Nov 2007 01:48:59 GMT

Thanks for the feedback and thoughts. The second part is still not fully baked yet, so I’ll encorporate these notions.

Anthony Colfelt — Mon, 21 Dec 2009 17:19:08 GMT

I didn’t mean to make an impression that you need someone dedicated to each skill, but rather that you should aim to have the skills you need covered by the various staff you hire. These definitions are a means to divide the things we do into buckets, not to state the sole domain of any one person. My personal opinion is that you need at least some level of skill in each of these areas to do good design. I like Christina’s role definitions: ” * Conductor/leader * Finder-outer of user needs and behavior * Structural designer (IA, IxD) * Interface and visual designer * Realizer in the native web format (web dev.)”. This presents a nice abstraction from established role and job titles. It encourages us break our thinking out of them and I think that’s healthy. What skills you need has everything to do with your context… and that’s part II. :-)

Anthony Colfelt — Sun, 02 Mar 2008 23:31:00 GMT

Thanks Gabe, fixed it. :-)

Anthony Colfelt — Sat, 12 Jul 2008 04:46:00 GMT

Dan, you’ve made a useful distinction there between variety and context switching. Thanks. I didn’t express that very well, but was thinking more along the lines of what you’ve said when I wrote this. Quickly switching contexts (i.e. completely different environments, problems, skill requirements and even sometimes teammates) is what I was trying to express when I referred to variety in a somewhat hamfisted way. Good point about the political skills required of the in-house player too. :)

Anthony Colfelt — Mon, 14 Jul 2008 15:50:16 GMT

Hi Justin, your grandfather was a wise man. I hadn’t looked at it this way, but appreciate the difference between personality and character you’re drawing here. As you say, it really is what’s on the inside (character) that’s the important thing to try and get at when interviewing people. It’s hard to do in an interview, because you get personality, but not necessarily character. I’ve been burned by this first hand at a company I once worked for. A perfectly charming chap on the surface turned out to have a toxic character. Perhaps checking references is an avenue to explore in assessing this? But can you expect real honesty from referees who have been hand-picked for a favorable review of the candidate?

Anthony Colfelt — Fri, 07 Jan 2011 19:41:08 GMT

Great question, Robert. A lot depends on how people measure their success and fulfillment. Lets say that is tied to the quality of their output/product, as it often is in situations where expectations aren’t met. If no space, time or money is put toward the execution of quality, it will be hard for the entire organization to feel proud of their output and in turn, themselves. The issue could lie in so many areas, it’s hard to generalize a solution. To ensure a good environment, you might investigate three ‘Ps’ of potential weakness: Process, Politics & People. A process should ensure the right people are involved at the right times, doing the right activities. The political environment should not be adversarial or so competitive that it undermines morale, productivity or the success of the company. The people in the organization need to be supportive of best practice in all disciplines, as well as be appropriately skilled and utilized. If all these are right, then your Dreamteam should thrive.

Anthony Colfelt — Sat, 16 Aug 2008 01:27:09 GMT

It really depends on the organization and size of team, Jon. I’ve seen the design team as part of the marketing group, a production group, an engineering group and free standing. So where design fits into the organization needs to be negotiated, but you want a boss sympathetic to the cause of user experience design. I have found that marketing or production groups make good bedfellows with design. Free standing also works providing the manager is able to play nicely with the other group managers at his/her level.

Within a large team, members can report to a head of their discipline, e.g. heads of IA, visual design, research, etc. Smaller teams are often split into IA and visual design, with a team leader of each or all reporting to a head of experience design. If you have dedicated researchers/usability analysts, they can fit comfortably with IA functions managerially.

Matrix structures involve a manager of each discipline and managers of clustered related projects. So most people then have two managers, one of whom remains constant (discipline manager) and another who may change according to what project they’re working on. The discipline manager then looks after all things career and skills wise, the other manager looks after work being done on the project.

Anthony Colfelt — Wed, 03 Mar 2010 14:43:34 GMT

@ Isaac Loloely As you say, it’s easy to step on these mines. But, with experience, you can avoid them if you incorporate some good product development and UCD techniques. There are a few things you’ve said that I’d like to discuss.

(1) You’ve stated that scrum has a requirements gathering process. But I disagree. I think what you’ve described is a requirements DEFINITION process and there is a subtle difference. One is about working out what requirements to write down (gathering). The other is how you write them down (definition). What I advocate is that there is proper rigor applied to gathering via deep empathetic design research, some of Indy Young’s mental modelling technique or similar, then defining them through stories.

(2) XP describes a customer as your client. Frequently when you’re developing software for a client, that client actually has customers who will be using the product you’re building. I’d advocate that in this case, you need to be testing with that end customer, not just your client, who may have no better idea about what the end customer understands than you do.

In the case where the client is representative of the user of your software, having them on site allows them to get quite familiar with the difficulties you face and they sympathize with the trade offs you have to make. They get “Stockholm Syndrome” (i.e. identifying with their captors). They lose fresh eyes and become less critical as they become more and more familiar with the developing product. Great for the development team, not so great for the other users who will have to use the product on which your client has compromised the best UI. This is why we usually try not to user test with the same participant more than once. The more familiar they become with the interface, the less likely they are to help you see what is not intuitive about it. I know that there are some interfaces we design to be learnable before instantly usable, but still, these interfaces needs to be intuitive to learn too.

(3) You make a very good point. No process can guarantee that someone with the power to do so will call it “good enough” before time. However, by incorporating some UCD techniques such as user testing, we can implement some gating success criteria that go beyond just what the client (with an eye for saving money) would normally accept. Of course, we’d do this in the best interest of the client’s longer term development cost, since hopefully, they’d not need to come back and redo it again and again for what would have been cheaper to fix (in dev cost, customer acquisition or in brand damage) at the first time of development. The same goes for proper QA. The war story I told a the beginning of the article suffered greatly from Mine 4 at the expense of user testing AND rigorous QA. Why? Because we were slavishly following an Agile process rather than being pragmatic about what would ultimately be the best thing to do.

Anthony Colfelt — Wed, 03 Mar 2010 14:43:08 GMT

@ Michael, you seem to think that I’m advocating for a big up front design process devoid of developers, but I’m actually not saying that. Yes, I am saying you need to do research and some modelling, but not exhaustive detailed design that specifies each and every detail. Your bad experience with a “full UCD methodology” that saw you launch something 5 years out of date sounds like you just took way too long to launch your site. Is that the fault of UCD techniqes? Or a lack of urgency? 5 yrs is a large gap between idea and web product by any standard. . I would say it is unfair to place the blame at the feet of UCD. After all, it is a philosophy – just as Agile is and does not mandate deep dive waterfall. Though some do get dogmatic about doing either in a particular way.

In a place such as the BBC, where you have ample talent, creativity, a core value of quality, far less drive to get things done quickly and an editorial heritage that doesn’t lend itself to software development, Agile is a perfect solution. Why? Because these qualities demand you get the product right and they’re more important than the imperatives which drive other commercial companies into cutting corners for perceived savings. This environment somewhat coccoons you from the experience so many others have. These people, particularly those who put design and build in the same sprint can fail to produce anything good and have a miserable time in the process. How do you save money paying a team of people to build something that doesn’t work for the user? Fact: Using paper and pencils is far cheaper than writing code. Developers can use pencils too! Fact: You can learn a great deal from user testing paper and pencil regardless of the richness in the interface. There’s a lot of value in a prototype, you agree. But you seem fixated on that prototype being high fidelity, working code. I don’t buy that is the only or most cost effective way to learn. There is a time for testing working code and that’s once you’re confident you have the broader brush strokes of overall proposition and information structure right for the user. All applications have this. Not just flat websites.

The other great topic for discussion is: What is design and who does it? Naturally, every team member’s work has an impact on the user’s experience. Only some work at the part the user touches. Some of those have a job title that suggests their primary function is to worry about that before all else: User Experience Designers. For the purposes of this article, that’s who i had in mind when I wrote “an unclear role for design”. It’s interesting quoting Steve Jobs to back the point that design starts on the inside. But that isn’t actually how Apple works. The first thing Jobs looks at is a photoshop comp or a sketch that defines the user’s experience. Not a working prototype to be “skinned” later (which is his point). When Jonathan Ives designs a new peice of hardware, he sketches it (and the outside first not the inside). Sure, good designers appreciate how things have to work. But the point is, it has to work for the end user and there are some disciplines which are more tuned into that world than others. No database architects I’ve known are focused on or skilled at designing a GUI that is easy or fun to use. I’m sure they exist, but I haven’t run into this special breed of unicorn. But that’s not what you’re getting at with the Twitter example.

This opens up a different point. Who are users? Are the patrons of an open API users? Yes, they are and perhaps our database architect is a better designer for this “persona”. Could database architects benefit from an API user persona? I’d like to think that makers of third party products have needs and goals too. Interestingly, these API consumers sometimes need to make GUIs at the end of the day because raw data is kind of opaque to their customers: “Joe Public”. So I don’t think caring about how that gets done puts me out to pasture just yet. But thanks for the inference.

Anthony Colfelt — Wed, 03 Mar 2010 14:42:38 GMT

@ Michael – I don’t think our view points are actually completely different in practice. I talk a lot about design activities in the context of the interface for the purposes of this article, because the people who design them suffer the most when companies adopt Agile and these same people frequent Boxes and Arrows. I agree that the world can change and quickly, and I agree that developing in an iterative fashion using agile methods is usually an excellent way to go providing you don’t step on any mines. In practice, a multidisciplinary team making design decisions together is the best way forward because you do get all kind of design going on in parallel.

Starting at the UX layer, in my opinion, is not always starting at the interface layer. It’s about understanding what the right user experience is, regardless of what channel they touch and the medium they use. I think we agree on that too.

We will have to agree to disagree about personas and paper prototypes. I believe everyone benefits from personas because they stop us talking about ‘The User’ as some amorphous conglomeration of our own perspectives and forces us to adopt different lenses to look at the same problem. I also agree that our assumption of what will work can change slightly when we put an idea into working code (usually not fundamentally). But I can’t get past the fact that you learn a great deal from testing on paper and thus can save yourself a great deal of heartache, even if you add to that learning with working code.

Thanks for the comments, It’s great to have some good Socratic dialogue around these thorny issues!

Anthony Colfelt — Wed, 03 Mar 2010 14:42:31 GMT

@Andrea – prototypes are a vital part of the product development process regardless of process or approach. There are lots of different levels of fidelity we can choose and each is best suited to different purposes. Low-fi is very valuable for validating core principles and flow. High-fi gets you conclusive evidence as to the efficacy of the final solution – particularly rich interfaces or complex solutions – but obviously this costs more and at some point we need to asses the risk of developing our proposed product without seeing it in a prototype. How new or different an implementation is it?

But whether this is the best way to address the business not knowing what it wants is debatable. Yes it is a very good tool, but there are other ways to guide a business toward a great user experience that involve really understanding the problem they’re trying to solve (a.k.a. “the opportunity”). This involves a number of different types of research to uncover various opportunities i.e. design research with methods such as Contextual Inquiry to understand user behaviour; or comparative research that looks at analogous experiences in different industries and markets; or technological research that identifies trends in technology that may lead to some interesting ideas. This step narrows down the strategic options to the right playing field and provides some great fertile soil in which to plant idea; in so doing it maximises any investment in a prototype.

Anthony Colfelt — Mon, 15 Mar 2010 22:43:42 GMT

@Praveen – I understand your frustration well. But I think it’s interesting that Agile has become so popular and surmise that it’s success must be attributed to more than the promise of saving money alone. There are definitely things wrong with the way many organisations do waterfall for which Agile provides a solution. However, a philosophy or approach alone cannot create good products and Agile is no exception.

Part of what Agile has done well is to create a manifesto that easily communicates the tenets of this approach. I think this has helped people “get it” and adopt it so readily. It’s something I have mused on and concluded is missing from UCD. I am happy to be proven wrong, but I don’t believe that as a community we have created a UCD manifesto to help organisations grasp what it means to be user centric.

Just as some of the programming legends gathered to define Agile’s rules, wouldn’t it be great if we could pull together the likes of Alan Cooper, Jakob Nielsen, Don Norman, Jared Spool, Karen Holtzblatt, Hugh Beyer, Jesse James Garrett and others to form a UCD manifesto? What would the rules of a UCD approach be?