Since the middle of December I have been working on a project design and help build an edu­ca­tional web­site for doc­tors. The project is a col­lab­o­ra­tion between a pro­fes­sional orga­ni­za­tion, a con­sul­tancy, a solo­pre­neur, and the com­pany I work for. The project has not always pro­ceeded without prob­lems and I’ve spent time thinking about how my work process and client inter­ac­tions will change the next time I have a sim­ilar assignment.

This exer­cise is not unique to this project. I learn some­thing from every project as I imagine all good designers also do. The dif­fer­ence is that this project has been so long and, at times quite dif­fi­cult to manage. And admit­tedly I’ve made some sig­nif­i­cant pro­ce­dural mis­takes along the way. So here are a few of my thoughts on the subject.

Take own­er­ship, but don’t revoke it from others

There are two habits I’ve had dif­fi­culty con­trol­ling. The first is becoming overly-invested in my work. I take my work per­son­ally. I want it to be the very best work that I can do. This con­tributes to two out­comes. First, I am never sat­is­fied because a project is always a com­pro­mise between my best inten­tions and the client’s wishes. These two forces are not nec­es­sarily in oppo­si­tion, but they don’t always (okay, they rarely ever) match per­fectly. Second – and related closely to the first – I will occa­sion­ally clash with my client when I don’t think they’re making good choices. This isn’t very pro­fes­sional and it’s not ever a good idea. In my defense, it (like other roads to hell) comes from good inten­tions. As a cre­ative pro­fes­sional, it is my pur­pose in a project to guide the client through the cre­ative process and make design deci­sions. Those deci­sions have (or should have) good ratio­nale to back them up. Clients, of course, are seldom knowl­edge­able (and are not expected to be) about the design process and on many occa­sions want to make their own deci­sions. I try to be a good guide, but I know I step over the line on occa­sion. In the end, the client is the owner of the project who has pur­chased my ser­vices and exper­tise. They are not oblig­ated to listen to it, although the end result will some­times reflect that. My task is to be useful, not to take over the project. And, often, projects deal with sub­ject matter that I am not familiar with while the client is. Their own deci­sions may be prop­erly informed by a dif­ferent and no less valid ratio­nale. The best thing to do is to work toward an understanding.

This last idea is related to my second habit: assuming that the person I’m working with doesn’t know as much as I do. In daily life, this is often true. I say this as a clear matter of fact and not as a con­ceit. I’m a fairly intel­li­gent person. How­ever, in my pro­fes­sional life, the average is much higher. I see it all the time in my peers. Why should I expect clients to be any dif­ferent? Well, I’ve met clients or poten­tial clients before who were the prover­bial rotten apples in the barrel. Or per­haps their exper­tise and mine were so for­eign as to not allow for good com­mu­ni­ca­tion. The point, dear reader, is that I should learn not to have a low opinion of clients simply because they are clients and there have been a few “bad apples”. And hope­fully I have not given the impres­sion that I am unpro­fes­sional in my deal­ings with them. I always try my best. Like most people I’m only unpro­fes­sional in my head.

Don’t expect too much from the technology

I like to say that, these days, the tech­nology for media devel­op­ment is gen­er­ally so good that almost any­thing is pos­sible. It’s simply a matter of cost. Well, cost goes to the client. That cost trans­lates into dif­fi­culty for a devel­oper. And the reality is that while many things are pos­sible, the sys­tems used for day-to-day “real world” media devel­op­ment are lim­ited. It can take an extra­or­di­nary amout of work to bend those limits for an end ben­efit that does not match the work involved to achieve it. In addressing that issue, devel­opers need to be part of the design process. There needs to be someone involved who speak to the fea­si­bility of a design and offer sug­ges­tions for how designs can be mod­i­fied to achieve the same results in com­mu­ni­ca­tion and user expe­ri­ence but cost less to pro­duce. And as I am learning, the dif­fer­ences between costly and rel­a­tively inex­pen­sive are often very very subtle and depend on the quirks of the sys­tems used for devel­op­ment. And because fea­si­bility should be assessed before a design is approved, devel­opers need to be involved very early in the process.

Plan­ning isn’t just helpful; it’s vital

I under­stand the value of plan­ning. In design, that typ­i­cally means cre­ating sketches or wire­frame dia­grams of a design or user inter­face. How­ever, this can be time con­suming and add cost to a project that a client doesn’t want to deal with. They just want to see the visuals. I’m begin­ning to see how this kind of visual plan­ning is crit­ical to a project and should be a promi­nent step in my design process. Per­haps it’s not some­thing a client ever needs to see. But this step can be of great value to a design team or a designer/developer part­ner­ship. As I step fur­ther away from the devel­op­ment work and con­cen­trate on the role of designer, this kind of plan­ning becomes increas­ingly necessary.