My name is
Jack Moffett. I am an Interaction Designer with over ten years of experience. According to
Herb Simon, that makes me an expert, so I must have something worth sharing. I have started this venture as an exercise to spur critical thinking about my chosen profession. I hope that others may find it thought provoking as well.
DesignAday will present a brief thought about Design every weekday.
Following up on yesterday’s post, I have some suggestions for dealing with those senior engineers that are set in their ways and uninterested in, if not hostile towards, interaction design. Here’s a persona that may or may not be derived from developers I’ve worked with in the past.
John Stern
Senior Software Architect
- Holds a Ph.D. in computer science.
- Knows he is smarter than you.
- Philosophy behind architecture of the system trumps all.
- Set in his ways, like an old dog.
- Highly risk averse, so doesn’t like trying anything new
- Doesn’t really care about design, because he doesn’t car.e about the UI or the user.
- The first time you ask him if you can do something, he immediately says no. Five minutes later, he comes back and explains how you can do it and why it will work.
- Ultimately, he is more interested in publishing a paper about the software architecture than delivering the product.
John may be the hardest developer for you to learn to work with. He’s going to cause you to mutter under your breath on a daily basis. Here’s my advice for turning what seems to be an impossible situation to your advantage.
- Show him some respect. He has earned it, and while he may be misguided, he’s no idiot. Don’t try to play top dog, because he’ll fight you for it. I’m not saying you should be submissive, but treat him as an equal. Don’t play the superior, I-know-something-you-don’t type of designer that we are so good at.
- Let him know your credentials. He has a lot of respect for higher education, so he’ll give you a few brownie points and the benefit of the doubt if he knows you have a degree.
- Try to couch your design decisions as solutions to his problems. Convincing him that you are going to make his life easier should be your number-one goal.
- Learn to read UML diagrams. Speaking his language will not only improve communications and earn some rep, but will give you a better understanding of how your designs fit into the overall picture.
- When trying to introduce something new, preempt his rejections by providing supporting evidence: examples of use, code samples, and any requirements, such as versions, incompatibilities, and the like. He’ll take your suggestions more seriously if you show that you’ve done some research into their feasibility.
- Be patient. Try not to be confrontational. He may never fully appreciate your contribution, but he may come to respect you for your process, rigor, and attention to detail. Those are things he can relate to.
Midwest UX starts tomorrow. I’ll be driving to Columbus as soon as I can get away from the office. If you’re going to be there, please look me up. I’d really like to meet you!
There’s a lot of content that won’t fit into the forty minutes I am allotted for my presentation this Saturday at Midwest UX. So, I might as well share it here.
One trend I found in my survey results supports my own personal experience working with developers. The older the developer, the more likely they will be difficult to work with. I realize that’s a very generalized statement, and it depends on the individual, but take the following response:
“I find there to be a difference between some of the older developers and younger developers. The older ones are a little confused by my role as an interaction designer. The younger ones really seem to value my input and user centered design processes. They are excited about the changes and like to contribute new ideas. The older developers who seem to have a different school of thought start shaking their head as soon as I stop by their desk with a fresh stack of sketches.”
This is likely a case of people being set in their ways. They have been practicing their profession without an interaction designer for years, so why do they need one now?
“It seems to be a matter of how long people have been here. The folks who have been here longer seem to resent my addition to the team and cause the most problems. The newer people don’t seem to have a problem with my work.”
Of course, it’s much easier for a new hire to accept an interaction designer as part of an established process. That’s their baseline as they become indoctrinated to the company’s culture. Contrast that with an interaction designer hired into a company that doesn’t already have a design-oriented culture. There’s a huge difference.
“Its the old school developers who are the hardest to work with. it seems like from their view point there is no reason why they shouldn’t be doing the design work.”
So, how can you turn this situation into a mutually beneficial working relationship? I don’t have any magic dust—it’s likely going to be difficult—but rest assured that with patience and perseverance, it is possible to gain the respect of the senior developers and pull them back to the light side.
Check back tomorrow for a few tips on teaching old dogs new tricks.
There’s a relatively recent question posed on Quora asking “How do UI Designers work with engineers to ensure their vision is achieved?” Owen Otto, a UX designer at Google, gives a very thorough answer that is right on the money. In brief:
- Figure out which type of engineer you’re working with
- Skim all bugs and code reviews for the product
- Do some front-end coding (but not too much)
- Sit by engineers
- Show the vision
- Involve engineers in user research
- Choose your battles
- Don’t whine
I encourage you to go and read his complete post. It’s no coincidence that most of Owen’s points are addressed in my upcoming talk at Midwest UX: Working with Developers for Fun and Profit. Owen is one of many designers reaping the benefits of tight integration with their development teams. If you want to learn more, register for the conference—it’s very affordable—and sit in on my presentation. Then find me afterwards and pick my brain. I’ll be more than happy sharing over a decade’s worth of experience.
Midwest UX posted the schedule for the conference that will be kicking off in Columbus, Ohio, on May 31st. I’m pleased as punch to be on it, but I was sad to see that I’ll be presenting at the same time as Joe Sokohl, who’s presentation I was looking forward to seeing. Titled The Digital Place You Love is Gone: Mitigating Loss in the Ethersphere, Joe’s talk addresses the emotions people feel when their familiar digital places dramatically change, or even disappear. I find this topic really intriguing and won’t blame you if you attend it instead of my own presentation: Working with Developers for Fun and Profit. Worse yet, it’s a three track conference, so if you aren’t into psychoanalyzing our attachment to virtual places, and you are already enjoying a tight integration with your development team, you might rather check out Chris Risdon’s talk about experience maps. We’re all three presenting on day two in the 11:30 slot.
If you find that a difficult decision to make, just wait until you see the full schedule: 2 full days containing 10 3-track sessions for you to agonize over! Oh, and don’t forget the 6 workshops on Friday. I’ve heard that there are still tickets available, so sign up now. If you do happen to sit in on my session, I promise to give you some good discussion topics for your lunch hour. Otherwise, you’ll have to fill me in on what I missed.
The results of the survey I conducted as research for my upcoming Midwest UX talk indicated that about 70% of the respondents do not use a version control tool, such as Subversion. I can’t say that I’m too surprised by this. Version control is traditionally part of the developer’s domain, and the tools are specifically geared towards code.
Of course it is necessary to use version control if you are a designer that works directly in the production code base. However, I’ve also been using Subversion to track all of my artifacts, from scanned sketches, to Photoshop and InDesign files, to HTML. It gives me great peace of mind to know that every version of every comp is easily retrievable. I don’t have to remember to save a new version of a file every time I modify it. I just check it in. This is especially valuable when you are collaborating with other designers. Your Subversion client ensures that you have the most recent version of every file and presents a history of changes made by all collaborators. And on top of that, your development team now has access to the most recent version of your specs within the very environment they are living in.
If you aren’t already a part of the 30% of designers that take advantage of version control, I encourage you to start utilizing it. I guarantee it will improve your process and lead to tighter integration with your development team.
The best sort of lectures are the ones you get lost in, never realizing the time passing. We at Midwest UX feel that each one of the following talks embodies that exact quality. Immersive, reflective, and innovative: each presentation brimming with fresh ideas and concepts designed to inspire.
I’ll certainly do my best to live up to that ideal. I’m happy to announce that I’ve been engaged to speak at Midwest UX, to be held in Columbus, Ohio, May 31st through June 2nd. Working with Developers for Fun and Profit will be one of twelve 40-minute talks. There are another seventeen 20-minute talks and eight 5-minute talks. Peter Morville, Nathan Martin, and Richard Buchanan are giving the keynote addresses. Six workshops are also on the agenda.
Tickets went on sale yesterday, and all fifty early-bird passes sold out. Regular passes are still available as of this writing. The event is being held at COSI, a wonderful science center that I fondly remember visiting as a kid.
This will be the first conference at which I’ve spoken since the International Symposium on Wearable Computers in 2000, so I’m rather excited about the opportunity. A number of my IxDA colleagues are presenting as well, so it’s shaping up to be a great conference.
Only 36% of the designers I surveyed participate in functional testing. In fact, the only activities with less participation are bug fixing, implementation, and the writing of user guides. That’s a shame, because designers make great testers! Good designers are detail oriented, a trait that is also important to testing. Designers use the system more like the users will than like the developers use it, so we will often discover issues that the developers won’t. On top of that, we know better than anybody how the system is supposed to work—we designed it, after all. Participation in functional testing also gives us the opportunity to find and document usability issues prior to usability testing.
Your participation in more of the development process is going to result in a better product and higher job satisfaction. Participation in functional testing is a relatively easy way to extend your influence and grow your technical knowledge.
Design documentation is not a one-size-fits-all product. There are a lot of differences between a small partnership building their own iApp and a software development firm doing millions in government contracts. Their documentation requirements are completely different. We need to design our documentation with the users in mind—specifically, the users of the documentation. Some documentation is intended for the customer. A lot of documentation is produced for the developers. It is important, then, to think about how the developers will be using the documentation.
I’ve been striving to design my documentation as a reference. That is, I try to make it easy for the developer to find information they need in the middle of development. Sure, I expect them to read the documentation ahead of time, so that they understand what they are to do, but it perfectly fulfills its purpose when, in the middle of coding a function, the developer has a question and is able to quickly find an answer. Long paragraphs of textual description and even bulleted lists are not the most accessible formats for such a use case.
“Ideally, the developers and I are to work closely together during the design phase… but it typically works out that they gloss over the document or attend a few meetings and get a basic understanding of what we are planning on doing, but never pay attention to the full details. Then they tend to come to me with questions or ‘Are you crazy? I can’t do that!’ when it’s time for them to put together a timeline for their development assessment.”
I don’t know the full context in which this designer works, so I don’t want to be too accusatory, but it seems to me that s/he isn’t taking enough initiative in establishing solid communications with the development team. We can’t afford to just expect developers to show up at our meetings or assume that they will thoroughly digest an entire specification. Sure, some may, but there are competing time-sinks. We need to schedule time to huddle with developers, individually if need be, to walk them through the design. Force the discussions about feasibility, technical challenges, complexity, thoroughness of the spec, and so forth. We can’t blame developers for a lack of attention if we don’t actively engage them during the initial design phase.
“I get most frustrated when, after providing a pixel-perfect mockup, I see the finished implementation during the testing phase, and it’s drastically different than what I spec’d (fonts, colors, sizes, spacing, alignment, positioning, etc).”
This comment was left by one of the respondents to the Working with Developers survey I circulated in December and January. It is a perfect illustration of why my topic is so important. There are too many designers working disparately from their development teams. We cannot expect developers to have the same visual sensibilities or attention to behavioral details that we have worked so hard to perfect. It is unfair to berate them for misunderstanding our design specifications when we do not participate in development activities.
The talk I gave last night at IxDA Pittsburgh’s event, Working with Developers for Fun and Profit, is intended to help designers solve this very problem through deep integration with their development teams. The survey was conducted as background research to make sure I had a reasonable understanding of practices outside my own experience. It resulted in a few insights, which I will continue to analyze and share here on DesignAday. For those interested in reviewing the full results, I have made them publicly available at https://www.survs.com/results/TMEFGAPC/13RJJY2M2T. If you have any revelations or questions about the data, please share them with me.
