While many developers have an intuitive sense of what looks right, they sometimes lack the vocabulary needed to express their hunches to designers and the rest of the team.

To help fix this common problem, EffectiveUI Senior Developer RJ Owen and Lead Experience Architect Michael Salamon are hosting a session at Web 2.0 Expo SF on Design Essentials for Developers, during which they’ll cover basic design techniques and principles; design vocabulary, heuristics and analysis techniques; how to do quick and dirty user testing and prototyping; and the difference between information architecture and interaction design.

RJ and Michael recently spoke to us about their upcoming session. You can read the full interview below.

Interview with RJ Own and Michael Salamon on Design Essentials for Developers

Kaitlin: Why did you decide to host this session? What particular problems were you seeing at your own company or others’ that made you think this training is necessary?

RJ: As a developer, I find myself frequently involved in making design decisions and really passionate about the way users interact with the applications I’m building. I think we-as-developers are in a unique position to be the first real deep testers of the software we’re making. It’s up to us to help identify design problems early, and this requires a set of tools and a vocabulary that most developers don’t learn in school or along the way.

At EffectiveUI we always hire developers who have strong opinions about design – even if they don’t have the background. We’ve found that people with opinions care, and people who care will take the time required to get the little things done properly.

Michael: It’s naive for designers to think that developers aren’t designing, and it’s in their best interest to arm their design implementers with all the knowledge they can. Unless you are supplying user interface specifications for every possible use case and error, then your development team is doing as much design as your design team is.

Kaitlin: It seems that the basis of your session is teaching developers to speak a different language – the language of designers. Is this merely about vocabulary or is the approach more related to a new way of thinking?

RJ: I think it’s both. Understanding something like the concept of an “affordance” really changes the way you think about them. I think it’s about teaching developers to understand a design from a fundamental level – to look at it and think about the way it “works”. It lets them apply a second level of deep-thinking to the interface. Normally a developer looks at an interface and starts thinking in terms of containers and functional components – the programmatic building blocks they’ll need to leverage to implement the design. We want to get them thinking about things like layout, the grid, contrast, use of space – to make them see the visual side of the application in a way that lets them better understand the purpose and intent of the design. We think this leads to better software.

Michael: Wow. RJ nailed it. I also want to take some of the mystery and snobbery out of design communication. Once everyone is speaking the same language you can venture into the deep design theory stuff.

Kaitlin: Knowing when to talk and give an opinion seems just as important as knowing how to communicate those opinions. Do you have recommendations or a good process for when/at what stage developers and designers work together?

RJ: It’s my opinion that developers should be intimately involved in the design process (and vice versa.) Developers obviously shouldn’t be spending every design hour with a designer, but it’s important that they be involved from the beginning. Similarly it’s important that design not throw things “over the wall” to development and then check out – they need to be regularly involved in viewing the app as it’s being built. Can you imagine an architect never sticking around to watch their building being constructed? As developers encounter what looks like a design problem, they should do a quick diagnosis themselves and try to understand the issue. If design and dev are communicating regularly then it’s easy to bring it up in a way that doesn’t delay the project and get the issue addressed. If there’s disagreement, we want to teach both teams some basic techniques for doing “quick and dirty” research to validate their opinions.

We require development leads to be intimately involved from the project start, including all client facing meetings. I personally rely on my development leads to be involved in early whiteboarding sessions and help me craft the design framework. On the other side of the project, design reviews take half as long.

Kaitlin: You’ll cover design basics such as layout, color theory, and typography, which on the surface sounds easy enough but could turn into a complex learning assignment. Why do developers need to know this versus just being able to point out the items that bother them and allow the designer to lead the discussion?

RJ: In order to have a really productive discussion developers really need to know more. Good designers are the first to admit that they want critique and that a single brain can’t solve every problem. If a developer can’t get past “I don’t like the way this looks” to explain what about the design bothers them, it’s less likely that their interaction with the designer is going to lead to a healthy dialogue and result in a better design.

Michael: I don’t expect to be able to rush through a classical design education in a conference session, but we can explore general topics a little bit more in depth and expose the conceptual framework that they are based on.

Kaitlin: The nature of being a successful employee has changed somewhat in recent years; to be effective, you need to have – or at least be fairly well aware of – multiple skill sets outside your own core talents. Perfect example is the developer/designer dynamic. What other skills should developers work to cultivate in order to push a successful product?

RJ: Another universally valuable skill to have is a working understanding of project management. Beyond that, developers should cultivate a basic knowledge of other skills specific to the industry they’re involved in. For example, EffectiveUI provides user experience consulting services in the form of customer insight, design and development. As a developer, I need to understand how to be a good consultant for my clients and how to interact productively with all the different parts of my organization. This means knowing a little bit about things like sales and account management as well, though I don’t expect every developer in every industry needs those specific skills.

Michael: I second the customer insight skill-set. Knowing what, how, and why a customer is inclined to use your product can only produce good results.

Kaitlin: What exactly do you mean by “quick and dirty” user testing? Why go the quick route versus something more in-depth?

RJ: Formal user testing takes a long time and can be expensive. It’s often difficult to justify that cost to any organization. By using some simple techniques to validate design problems and solutions in a “quick and dirty” manner you can get a rough idea of the eventual problem without having to spend a lot of time and money. It helps projects stay on schedule but adjust the interface where needed. Where the quick and dirty route fails to help the team find good solutions, more formal methods may be required to build a really good interface.

Michael: Another stellar answer from RJ.

Kaitlin: Do you have a good example/case study you can share of how a developer can give quality feedback on design?

RJ: Off the top of my head I don’t know anything I could point to – it’s really a more of a conversation, so it would take some time to relate a story of a time this has helped us. We can show some finished products that have resulted from good collaboration though…

Michael: I think they do it all the time – it’s definitely a collaboration thing.

Kaitlin: What are the biggest Lessons Learned for your team so far when it comes to effective development/design communication?

RJ: 1. Involve both teams for the entire duration of the project – they don’t need equal hours at all times, but it’s important not to leave each other out of important decisions along the way, and the best way to get in a groove as a team is to work together consistently.

2. Validate, validate, validate! As designers and developers we work on this stuff all day and have lost any sense of objectivity we had towards an interface. We can make educated guesses, but in reality we often have no idea how a user will react to any new interface metaphor. It’s important to validate even simple things with users to get this kind of feedback early and often.

3. Design and agile development are great friends. Frequent user validation plays into the agile sprint planning really, really well.

3.5 Design can integrate into the Agile process via established design deliverables. Sketches, Frameworks, Wireframes, Comps, fit nicely into the stand-ups.

4. Never stop communicating, and encourage drive-by reviews with everyone on.

5. Good ideas come from everyone on the team.

~~

Kaitlin Pike is the Web 2.0 Expo community manager. She can be reached @w2e or @kcpike. To see RJ and Michael speak, register for Web 2.0 Expo SF now with  discount code websf11bl20 to save 20%.

Trackback URI | Comments RSS