processes & methodologies

About

Syndication

Categories

Archives

Scheduling Tasks Collaboratively

processes & methodologies

May 29, 2004, 09:16 PM

Our capstone project has entered its second phase, where we're doing iterative testing and redesign work. The biggest change is that we're all working on the project full-time now, rather than around 12 hours a week as one class among many. The best part about this is that Bob got each project team it's own shared office space (ours has a window! Yay!). This constant proximity has proven extremely helpful for our team so far, and has allowed us to try out some collaboration techniques we weren't able to do before.

One problem we suffered from last semester was group task management. People would commit to tasks but wouldn't always follow through with them, not out of laziness but just because they'd fall by the wayside and nobody was really keeping track. People weren't always terribly aware of what everyone else was doing (including me, the project manager). This cost us a lot of time in meetings coordinating with each other. I kept a detailed schedule for a while, but gave up since it kept falling out of date and nobody ever really looked at it anyway.

Once we got our summer space, I had an idea for how to improve matters. I bought a roll of butcher's paper, some Post-It notes, and markers, drafted a much larger version of my linear schedule format, and posted it up on the wall. Here's some photos of the entire schedule and a close-up of the first couple of weeks:

Whenever someone takes on a task, they write it on a Post-It and stick it up on the date they think they'll complete it by. Project milestones and scheduled events such as client meetings and user tests are also put up on the board by the person who was in charge of scheduling them. During our morning check-in meeting, we go through the tasks that were scheduled for completion that day, check off those that actually were completed, and move those that weren't to a new deadline.

We use different colored Post-Its to represent milestones, events, and tasks assigned to different people. Some immutable events (such as team member absences) are written directly on the board itself.

This approach to group schedule management has several advantages:

1. Everyone can always see the schedule. Because it's up on the wall staring at the entire team, anyone can just glance up and see both what tasks they've currently committed to as well as what tasks everyone else is working on. This is a huge benefit when many of your tasks depend on deliverables other teammates are currently working on (an extremely common scenario in interactive design projects).
2. Team members must commit to deadlines. Because there is no space on the board that isn't situated in time, there are no "floating" tasks that someone is working on but hasn't committed to a deadline or deliverable. As soon as a task is defined and assigned, the assignee must make at least a rough estimate of when he or she expects to complete it.
3. Schedule slips and dropped tasks become explicit decisions. Post-Its can be moved or removed, but the team member responsible for the task must consciously make that decision, probably in front of his or her teammates. Though the mobility of Post-Its might encourage overly flexible deadlines, I believe this is necessary for the schedule to stay in sync with reality (and there are other mechanisms for preventing schedule slip, such as the next one).
4. The amount of time remaining before deadlines is immediately visually obvious. The project milestones and completion date (where the timeline itself ends) are plainly visible for all to see. Because days all take up the same amount of space, team members can quickly see how much time is left before the next approaching deadline and experience the appropriate emotional response.
5. The team can get a rough sense of who is overcomitted and who has some time to spare. This is possibly the least useful feature, but because the tasks are all visible, the team can get a rough idea of everyone's level of comittment, past and present. Simply counting Post-Its won't work, of course, since some tasks may eat up only a little bit of time now and then whereas others may suck up the entire day. But the board at least provides a starting point for a conversation.
6. Everyone owns the schedule. If only one person is charged with maintaining the schedule (usually this is the project manager's responsibility), then the rest of the team is encouraged to concern themselves only with their immediate tasks and not take a big picture view of the project. Tracking everyone's individual tasks can get quite tedious for the project manager while also giving everyone else the impression that he's micromanaging. Having the schedule accessible for viewing and updating by everyone encourages collaborative ownership of the long-term direction of the project (provided the board is truly owned by the team and not just a tool for the project manager to keep an eye on everyone). A schedule maintainer is still needed, of course, but now he or she must simply be there to make sure the board stays up-to-date and to direct the team's attention to long-term trends and future milestones.

The core benefit, of course, is much the same as that provided by affinity diagrams, that is it takes abstract concepts (time and tasks) and makes them visible and physical.

There are some drawbacks, as well as situations in which this approach might not work so well:

1. The board requires a fair amount of permanent wall space. Teams that don't have dedicated project space (ideally shared by all members in a radical colocation style setup) can't use this approach. Even teams that do might have trouble finding enough space, especially if the board is introduced into an existing project room. Fortunately, we were setting up our space at the time that I had the idea, so this wasn't an issue, but if the team already has posters or whiteboards or whatever covering the wall, there might be pushback.
2. The board may not scale to long-running projects. In the same vein as the previous point, long-running projects may require absurdly large boards. The one you see pictured above is for 12 weeks, and it wraps around to two walls. Projects that last a year or more can't put their whole timeline up, but perhaps it would be sufficient to stick up only the amount of time between project milestones, or enough for a three-month span. Longer-term planning can be done through other means; most teams are probably more concerned with what they're doing in the next three or four weeks than in the next four to six months anyway. However, this compromise might lose some of the long-term view of approaching deadlines that our board enjoys.
3. The board may not scale to large numbers of people. We have five people in our team. If we had many more, the board might get cluttered with Post-Its and it might get harder to read and manage. Then again, if you have a team with many more people things will get unwieldy no matter what you do. But I could reasonably see a team with around 12 people wanting to use this, and that may be more than it can support.

Maybe I'll write a paper on this topic. I'll call it "A Cost-Effective Large Display for Collaborative Scheduling and Ambient Task Awareness using a Tangible Interface". I think it could totally get into CHI.

[ Permanent Location ]

Life Lessons for Designers

design, processes & methodologies

March 26, 2004, 10:16 AM

Found via Dan, this article titled "The Top Ten Things They Never Taught Me in Design School" is interesting reading for those of us who are starting careers in one of the subdisciplines of design (or hoping to, anyway). Some of these ring true for me already, partially due to my (admittedly marginal) professional experience but also because of my experiences here at CMU (so some of them can be taught in design school, albeit indirectly). For example, I'll buy the "95% of any creative profession is shit work", especially after playing project manager for our capstone project. And this is important to come to terms with, because you probably won't be too happy or successful as a designer if you can't learn to take the bad (think convincing management that your design is important, writing up user testing reports, fighting with developers over technical compromises, etc) with the good (sitting down to do some creative design work).

Others I can certainly see as important, but I recognize that I need to get better at, like prioritizing and not over-thinking problems. And a few sound pretty familiar from my experience as a software developer, like "Start with what you know; then remove the unknowns".

It's good to remember, every now and again, that things work differently in the real world than they do in the ivory tower of academia.

[ Permanent Location ]

Ready, Fire, Aim: Parallelizing Design and User Research

design, processes & methodologies, usability

February 18, 2004, 11:48 PM

For our capstone project, we're reaching the point in our process where we agreed to begin thinking about design. As I mentioned earlier, we want to overlap our design and research efforts to avoid getting caught up in wasting lots of time doing up-front research that doesn't turn out to be useful for our design efforts.

Bob calls this approach "Ready, Fire, Aim". The basic idea is to spend some time preparing yourselves by exploring the domain, reviewing literature, talking to domain experts, etc., but then quickly pick a focus and start down a design direction. These early designs may turn out to be totally off-base, but at least they will serve to point out the holes in the team's understanding of the users and suggest fruitful directions for additional research.

I remember a similar concept appearing in programming practice. The Pragmatic Programmers recommend an approach to architecture design they call "tracer bullets". The idea is to attempt to construct a functional end-to-end skeleton system to serve as an initial prototype of the proposed architectural design. Although you may throw this away, you'll learn where the flaws in your understanding of the problem domain lie so that you can design a better architecture and fire your next tracer.

The challenge we'll face, I expect, lies in keeping a clear vision of the team's current understanding of the users and their needs. This is likely to change with the designs as we uncover holes in our knowledge and fill them in. Our plan at the moment is to encode this understanding in our personas and task lists, hopefully using these as living documents as the design process progresses. Perhaps this will be sufficient, perhaps not. It will be interesting to see what this process produces and whether it will be successful.

[ Permanent Location ]

The Art of Being Critical: How to Give Design Critiques

design, processes & methodologies

February 16, 2004, 08:13 PM

One skill that is very important for a designer of any stripe to have, but which I've found is rarely explicitly taught, is how to give and receive effective criticism in a design critique. As a result, I find when someone asks me for feedback on a design I often don't know quite what to say, and when I ask others for feedback sometimes that feedback isn't as helpful as it could be. This can be a big problem, since often this form of feedback is all a designer gets, especially on those many projects that aren't important enough to warrent user testing. So to start to address this problem, I'm outlining some thoughts on what should and should not go into an effective piece of design criticism, whether this criticism is given during a formal crit session or in response to a friend asking "whaddya think of my poster?" over lunch the day before an assignment is due.

First off, it's important to remember to check your ego at the door, to criticise the work and not the person, blah blah blah. We all know that already (even if we don't always live it). What else is there to say?

When offering criticism, I'd first ask "what is my initial reaction to the work?" How does it make me feel? Confident? Playful? Annoyed? Confused? Where does my eye go first? What information is most prominent? What do I think the designer was trying to accomplish with this work? Anyone, even those with no design experience, can give useful feedback along these lines. And sometimes its these first impressions that are most helpful.

Next, make sure you're clear on the designer's goals with respect to the work. Don't guess; ask him. It's easy to suggest changes that aren't appropriate not because they aren't great ideas for some purpose, but because they aren't so hot for the intended purpose. Design is an inherently normative act, and thus it is always performed in service to some set of goals. You might disagree with the author's goals, but then at least you're clear on what it is you need to argue about. Alternatively, the designer might not be clear on what his goals are. This is a problem. Maybe you can help him figure that out before proceeding.

Once you're clear on the goals, you can start to apply that design expertise by comparing and contrasting the design to a set of principles and best practices, as well as an understanding of the needs of the intended audience. It's best to describe both problems and good aspects, so that the designer understands not only what needs to change but also what he must avoid damaging with changes. However, don't fall into the trap of applying principles without proper justification. All principles have reasons behind them, and those reasons don't always apply. I once knew a guy who insisted that "you should never provide help unless the user asks for help". A good principle, probably born out of the Clippy fiasco, but he believed it so religiously that many of his interface designs would fail to provide sufficient feedback for users to evaluate their actions under the theory that it was "providing help the user didn't ask for" (some screens he left entirely blank, with no explanation of their lack of content). Novice designers often apply their shiny new design principles haphazardly, and as a result may do a worse job than they would have were they ignorant.

Try to understand design tradeoffs; make a note of parts that could be improved but also say whether you believe the problems are serious or just small refinements. All design must be signed off on at some point, and its useful for the designer to know whether you think his solution is pretty good as it is or needs much more work.

Finally, don't get upset if the designer challenges your suggestions. He might be too in love with his work to take criticism, yes, but he might also just be trying to better understand your concerns so he can decide how best to improve his work. Give him the benefit of the doubt and assume it's the latter.

When receiving criticism, it's best to be open but inquisitive. Listen to all design suggestions but don't always take them at face value; you may need to probe to get at the reasons for the concern. It can also be good to get a second independent opinion if you're not convinced; see if both your reviewers come up with the same issues independently but if they don't, ask them about it specifically. Try to avoid biasing them one way or the other.

Perhaps after waiting for initial impressions, make sure you've made your goals clear. Your reviewers can't give useful feedback if they don't understand what you're trying to do.

Finally, remember that critiques are analytical analysis methods, not empirical ones. You must judge critique comments, both as a designer and a reviewer, by the quality of their arguments, and to do so you must first understand the argument. Both parties must be able to divorce themselves from the context in order to do so, but it takes a present mind as well as an absent ego to actually affect useful design change. Remember that pushing pixels around on the page doesn't always equal progress.

Good critiques can transform bad designs into excellent ones, but they aren't trivial to run. It's a skill that takes practice, just like anything else.

Scott Berkun, a man who is probably far more qualified to pontificate on this subject than I, wrote an article about how to run a design critique that may be worth checking out as well.

[ Permanent Location ]

Camera Studies

design, processes & methodologies

February 05, 2004, 11:15 PM

Sonia Wendorf, the resident industrial designer on our capstone project team, has introduced us to the concept of "camera studies" and is currently designing one for our own data collection purposes.

A camera study is a user research technique where the research team gives participants in the target user group disposable cameras and asks them to photograph important events, objects, and places they encounter during their day, as well as possibly writing down quick notes describing what they're doing and why they took that particular photograph. Alternately, the researchers may just ask the participants to take one photograph about every hour to collect more time-based data. The researchers then develop the film and review the pictures to gain an understanding of what goes on during an average day in the life of their users. If necessary, they may do an artifact walkthrough with the users after viewing the photographs to gain a more in-depth understanding.

The purpose of the study is to gain a visual understanding of the user's activities and habits during their average day so that the design team can get a sense of their lifestyle. And because the researcher need not actually accompany the users during the data collection process, this technique can glean information from a broader range of users than, say, ethnographic observations can. One could see the results of such an inquiry feeding quite nicely into a set of realistic personas for a project.

The advantage of this approach is that it helps the design team see the world through the participant's eyes rather than just their own; the participant is filtering the information by choosing what to photograph. Furthermore, since the technique allows for running many users in parallel, the design team can get data on many more users which allows for richer data with greater variety. The downside is that the data collected won't be as richly detailed as the data an experienced ethnographer could collect during an extended observation session. So although the technique may be quite helpful for getting an overall impression of a participant's lifestyle, it's less useful for, say, understanding how that participant fits into the larger corporate organization or how the software they use impacts their job performance.

Anyway, it's an interesting technique to add to the toolbox. As an aside, Dan has a post up on a few more from Maya Design.

[ Permanent Location ]

Defining SMART Objectives

processes & methodologies

January 22, 2004, 10:18 PM

More wisdom from Matt on project management, this time on the topic of defining good objectives.

First off, Objectives need to be distinguished from Mission Statements or other expressions of general direction. When a team or organization expresses their mission, this is an important tool for maintaining a joint understanding of what the group is trying to accomplish by staying together and how every individual fits into the larger group purpose. Because the purpose of Mission Statements is to provide direction, there's not necessarily a requirement that the mission ever actually be accomplished.

Objectives are different. Objectives do need to be accomplished if a project is to be considered a success. The purpose of objectives is to provide a definition of that success and to provide it up front, so that all project team members understand what the group needs to do. Good objectives have five important properties. To remember them, PMs say that good objectives need to be SMART:

1. Specific—Objectives need to describe particular actions and results in quantifiable terms. For example, let's imagine a widget factory manager who is given the very vague objective from higher up to "increase production". To make this objective more specific, she might change it to "increase widget output by 3%".
2. Measurable—This means that each objective must have some sort of mechanism in place to check the extent to which it is getting achieved. If our factory manager doesn't already have something in place to count the number of widgets produced, then she'd better find something to do so.
3. Achievable—The objective needs to be possible to accomplish with a reasonable time and energy investment from all team members. This may seem obvious, but there are plenty of times that impossible objectives get set, often because the manager who set them didn't know enough to realize they were impossible and didn't consult with anyone who did. Our factory manager may wish to meet with workers and their supervisors to discover whether the 3% output increase is reasonable or not before she imposes it.
4. Relevant—The objective must be meaningful to all team members and it must be something they are able to influence. Presumably the factory workers under our manager are able to influence the widget output (although setting individual objectives, like 5 more widgets a day per person, might be even more relevant) but had our manager asked them to "increase profit margins" then she would have been greeted by blank stares. Relevance is, of course, determined by the people the objective is being set for. In a way, it speaks to objectives being user-centered.
5. Time-bound—The objective needs a deadline, or no one's going to ever get around to accomplishing it. Our factory manager should change her objective to "increase widget production by 3% in two months" to make it conform to this property.

This article describes each property in a little more detail for the curious.

Though these properties are simple in concept, writing effective objectives is harder than it appears. Make sure you understand the purpose of each property, and don't overlook any. After all, you don't want to wind up with objectives that are SMAT or SMRT.

[ Permanent Location ]

Setting the Agenda

processes & methodologies

January 19, 2004, 11:16 PM

Awhile back, my friend Matt taught me how to write a good meeting agenda. It's a simple skill to learn, but highly important for running effective meetings. Agendas are often skipped by novice facilitators, which all too often leads to wandering, ineffective meetings that waste everyone's time.

There are three important components to any agenda item:

1. The item description, which gives a one-line summary of what's going to happen.
2. The person responsible for the item, so that it's clear who will be facilitating that part of the meeting, and thus must come prepared to do so.
3. The type of the item, which is described in more detail below.

It may also help to allocate a time range for each agenda item. For formal meetings, these times are generally present and strictly adhered to. For less formal meetings, however, they can still be helpful as process checks to ensure an unimportant agenda item doesn't dominate the whole meeting, or cause it to run too far over.

The type of an agenda item is one of three options:

1. Information refers to an agenda item where one member of the group is going to report to all the other members about some topic. The other members are only expected to listen and ask questions, if necessary.
2. Discussion refers to an agenda item open to general discussion. All members may raise issues and voice their opinions, but no decision need be reached by the group.
3. Decision, on the other hand, refers to an agenda item where the group must reach a consensus. The item is not complete until the members have agreed on one course of action over the other available alternatives.

The type is an important component, since it makes clear to all members the purpose of each agenda item, allowing the group to deal with each accordingly. An item that must conclude with a decision probably needs to be handled differently than one that merely requires discussion, for instance.

A good agenda should give each group member a shared understanding of the meeting's purpose and tasks, at a glance. Without one, you'll likely face the Dilbertesque situation of series of pointless meetings that slow down the project rather than move it forward.

[ Permanent Location ]

An Obsession with Measurement

processes & methodologies

December 30, 2003, 12:33 AM

A policeman on the early morning beat sees a man, obviously drunk, standing under a street lamp and casting about on the ground as if he was looking for something. He parks his cruiser and asks the man "You there! What are you doing?"

"Looking for my keys, ocifer," slurs the drunk. "I lost them and I can't find them."

"I see. And you're certain you lost them under this street lamp?" the officer replies.

"Oh no, sir, I lost them over in that alley. But the light's better over here."

You've likely heard some version of this story before; it's an old one. The joke, of course, lies in the drunk's absurd belief that the better light will somehow help him find his keys. But its not always uncommon for beliefs like this one to get embedded into accepted practice, until no one realizes how absurd they are.

Tom DiMarco once said, "You can't manage if you can't measure." And without a doubt quantifiable measurements are invaluable tools; they provide objective proofs of progress and success, as well as early warning of impending failure. Processes that are founded on measurable objectives are almost always more efficient and effective than processes that are not. In a society founded on scientific values, it's unsurprising that measurability is often insisted upon by many managers.

The problem is that many valid and important objectives may be inherently difficult to measure. "Provide an excellent user experience" is one such objective, so is "improve programmer productivity", "increase the sense of community of our website", and "improve employee morale", for example. Yet rather than leave these important issues to softer evidence, often people will try to graft numbers onto the objective (efforts in software metrics, starting with counting lines of code, come to mind) or will just ignore the objective outright (especially if their incentives favor maximizing the quantifiable objectives). But now we're starting to look like that drunk under the street lamp; we're carefully measuring the wrong thing, just because we figure that somehow measuring something will be better than having no measurement at all.

That isn't necessarily the case. A programmer whose pay depends on how many lines of code he cranks out will write sloppy, inefficient, overly verbose code just to crank up the line count. A UI designer who will be fired if his interface doesn't start "passing" more in-lab usability tests will inevitably design for the novice users in the lab, probably at the expense of any other usability objectives. These examples of "metrics that miss" can be more of a curse than a cure for the project as a whole.

What's perhaps most frightening about all this is that any objectives that have to do with values or ethics are frequently notoriously unmeasurable. And they might be the ones that are most unsafe to ignore.

So what's the solution to all this? Only to think carefully about what exactly your metrics are measuring, and to not be afraid of techniques that yield softer evidence when quantifiable metrics just won't do. A quote attributed to Albert Einstein goes "Not everything that can be counted counts, and not everything that counts can be counted." Better light won't help you if you're looking in the wrong place.

[ Permanent Location ]

Divide and Conquer

processes & methodologies, writing & communication

December 16, 2003, 04:25 PM

Now, I'm thinking about team projects and efficient ways for several people to work on the same project.

In The Mythical Man Month, Fred Brooks confronts the problem of how to effectively divide up the work of large, complex software development efforts. He concludes that the project management notion that bringing more people on to the project will linearly increase the amount of work produced is a fiction, in fact new people will actually decrease the work output temporarily as they demand the current staff's time during ramp-up. Thus, the concept of a "man-month", which assumes men and months are interchangeable, is a fiction (hence the name of the essay). Even after ramp-up, adding more people to a project exponentially increases the communication overhead, since everyone must now potentially communicate with one more person to do their job.

The key issue here is that communication cost. When working in a group, you have to consider whether its possible to split up the work in such a way that the communication costs will be low. If everyone can work in parallel without talking, then you can just divide up the work into N pieces and if it isn't going fast enough, bring in more people to make N larger. Brooks' example of a task like this is ditch digging; if your ditch deadline is bumped forward, just hire more people, give them shovels, and dig in.

Unfortunately, most kinds of thought-work, which everyone in design, usability, research, and software development tends to be engaged in, isn't very much like ditch digging in this regard. Most of our projects are communication-intensive, and can't easily be split up in such a way as to make them parallelizable. Code has to work with other code, interface designs are too holistic to develop entirely separately, research must tell a coherent story, etc. What to do?

If possible, the best answer is "do it yourself". Many novice teams make the mistake of splitting up jobs that could be done way more efficiently by any one of them alone. Don't feel like you have to give everyone an equal amount of work at the expense of making everyone work harder than they'd otherwise have to.

If the task is too big for one person to accomplish, then your best bet is radical colocation. In Agile Software Development, Alister Cockburn recommends this technique for small teams that must engage in frequent communication, and he gives an extensive argument on why even moving people down the hall from one another can drastically limit communication opportunities. This generally leads to miscommunications, which leads to buggy software, unusable interface designs, misrepresented experiment results, etc.

So in summary: if possible, don't even try to split up thought-work; have it come from one mind. If that's not feasible, try to divide it up to minimize the amount of communication the workers will have to engage in to do their jobs. If the job is such that you can't reduce this to an acceptable level (which is more often the case than not, so don't be lulled into underestimating the amount of communication necessary), then radically collocate.

The nice thing about this advice is that it applies at all levels: from units as large as corporations outsourcing large initiatives to one another and as small as two people in a small student team.

[ Permanent Location ]

Maintenance Projects and U&SA

processes & methodologies, software development, usability

November 22, 2003, 07:06 PM

Turns out Dan wrote an article for Boxes and Arrows about a year ago titled "Tackling Maintenance Projects". The article is excellent and I recommend reading it. What I found most interesting, however, is how Dan's advice relates to the impact of software architecture on usability.

Dan draws a distinction between "Atomic Maintenance Projects" (more or less complete redesigns, of potentially both the interface and the underlying implementation) and "Neutron Maintenance Projects" (small changes that serve as point solutions but may not address the larger usability issues). The problem he observes is that often your client thinks they only need a Neutron fix, but after inspecting the interface you realize that an Atomic redesign is necessary to achieve adequate usability. In his words:

And there’s the rub. Often, IAs are left to wrestle with decisions that were made long before their involvement with the project; decisions that people in the company may not even like but are stuck with. Or decisions they have a vested stake in keeping intact. Or decisions various forces in the company (IT, Marketing, and Legal being typical stakeholders) insist must remain, for reasons the IA may or may not agree with.

Our hope with U&SA is that by bringing usability professionals (or designers or information architects or what have you) into the process at the system architecture design stage and giving them the intellectual tools they need to understand how to effectively contribute, we can reduce the need for Atomic projects so that more usability issues can be dealt with at the Neutron project level, which, as Dan correctly points out, is often insufficient given the current state of the practice.

[ Permanent Location ]

How the IT Industry Really Works

funny, processes & methodologies, software development

November 19, 2003, 04:29 PM

This cartoon is an oldie (I think I first saw it in "Developing User Interfaces" by Hartson and Hix), but it's worth repeating. It's a great 8-pane summary of the product development communication problems that I keep rambling about on this here forum.

[ Permanent Location ]

Discussing Disconnects

design, processes & methodologies, software development, usability

November 15, 2003, 07:08 PM

At the SSS two days ago, I led a discussion on how we can bridge the gap between interaction designers, usability professionals, and software engineers working together on real-world development teams (as I promised I would). I started out with a quick presentation describing the personalities and goals of both "players" (designers and developers) through some rough personas, then opened the session up for discussion on what techniques might help in getting these two players to work together effectively.

Here's a list of the possibilities that were thrown out for consideration. If anyone out there in readerland was at the discussion and notices something I missed, please do add it in a comment.

1. Emphasize more up-front design so design and engineering need not work in parallel. The idea is that this will reduce the amount that the two players need to communicate, thus reducing conflicts and making the process more efficient. It was also pointed out, however, that although spending time on up-front design is good, it doesn't solve all the problems. The final design, no matter how good, will still need to change quite a bit based on engineering's input and concerns, thus reintroducing the communication problem.
2. Design must bring engineering onboard. Those who came from an engineering background emphasized the need for design to justify and "sell" their design solutions to the engineering team. The idea is that although engineering trusts design to be good at their job, they will be more effective participants in the overall development process if they understand what the important usability issues are and why the related design decisions were made.
3. Design and development must "live" together. Basically, the two players should work closely throughout the entire process; there should be no "throw it over the wall" style information exchanges. I've suggested this before in the context of XP, going so far as to recommend that the two players work together in the same room.
4. Designers should contribute to development work. Many designers have enough technical abilities to contribute to parts of the user interface development process. In addition to speeding things along, this gives engineering a better sense that the designers are true members of the team. Cooper and Reimann suggest that one individual cannot fill the role of a designer and developer, due to the fundamentally different mindsets, but everyone in the group thought it was possible to strike a happy medium. In order to facilitate this technique, the software architecture must separate the user interface modules from the rest of the application using a separation pattern such as Model-View-Controller (which still won't handle all concerns, of course).
5. Designers should have engineers sit in on user tests. Watching users struggle with bad designs is often cited as a good way to motivate people who aren't willing to buy in to user-centered design. If this is the situation designers face, this is a technique they can try to bring engineers on board. Randy Pausch, ever famous for mistreating his engineering team, requires them to sit on their hands while watching people use their interface, and demands they keep silent unless they are willing to precede their comments with an apology for designing such a horrible interface. This might be a bit extremist for most industry teams to swallow, however...
6. Both players need case studies on how to effectively work together and how not to ineffectively work together. Design and engineering (and management) can learn from examples. Even experienced industry veterans may not associate usability failures with market failures, since these two events are often separated by a long period of time, and humans are bad at associating effects that occur long after their causes. Of course, someone must put together a collection of these case studies before designers and engineers can learn from them.

Perhaps the most interesting part of the conversation, however, was the discussion of the benefits of "creative tension", or those times when design and engineering don't get along yet wind up with a solution that is better than what they would have come up with if they had. Haven brought up the case of the Harley-Davidson VROD, a case study where there were several examples of the designers putting their foots down and demanding that engineering figure out a way to implement their design, as well as examples of the engineers demanding that the designers come up with workable designs. In the end, this resulted in a better product than Harley-Davidson would have come up with had the two sides come up with a compromise solution.

This raises the question of whether it is necessarily every desirable for design and engineering to get along smoothly, or whether a certain amount of tension and controlled chaos is sometimes necessary to produce a quality solution.

[ Permanent Location ]

Radical Colocation is a Good Thing

processes & methodologies, software development

November 15, 2003, 03:32 PM

Joel has an article up on the subject of adopting methodologies for software development. He makes a lot of good points about the state of the practice, but when discussing the subject of whether software development should occur in private offices or public collaboration spaces, he makes the following claim:

But we don't have the data. We don't have any data. You can give us anecdotes left and right about how methodology X worked or didn't work, but you can't prove that when it worked it wasn't just because of one really, really good programmer on the team, and you can't prove that when it failed is wasn't just because the company was in the process of going bankrupt and everybody was too demoralized to do anything at all, Aeron chairs notwithstanding.

This isn't quite true. Earlier this year I came across an article that came from