Developers vs. Designers

Here’s a comic and article at OK/Cancel about Open Source Software and how it has poor usability because of its nature (a programmer, or several, creating software because they have a passion for filling some need, almost always their own). The developers aren’t people who would do user-testing or UI iterations based on research and refined methods, and the lack of widespread adoption of open-source software is often blamed on poor usability (see “Slashdot”:http://ask.slashdot.org/askslashdot/04/04/12/1757244.shtml?tid=117&tid=126&tid=156&tid=185&tid=99).

As someone who has made a smooth transition from software engineering to UI Design and Human-Computer Interaction, I think one of my strengths is putting myself in the user’s shoes while still knowing exactly what’s possible and how long it will take to build. I’ve also figured out what it is that I like about both of these sides of software development. Software engineers get to do amazing design work, but that design work happens before they write a line of code, before anyone draws a picture of what the application is going to look like, and before there are any users. Well-designed class structures and object communications are lots of work and reap huge rewards in maintainability and ease of implementation, but they take a lot of time. It’s the same time that also needs to be spent designing user workflows and scenarios and appealing visual designs. And so with limited resources, one or the other suffers. With limited time, engineers put together the easy solution instead of what might have been more scalable or easier to fix, and designers throw in elements that could have been clearer or easier to use.

Designing from the engineer’s perspective and designing from the designer’s perspective share a lot of common characteristics. Both activities need to be done early, and the sooner you hit the sweet spot, the less you’ll have to tack on additional things you didn’t think of earlier. When either side overlooks something and realizes it later on, the solution just isn’t as good as if they had taken it into account to begin with. An engineer might realize one part of the application needed to access another part of the application’s data, and has to come up with a special-case bridge to make it all work. A designer might realize that a particular action is going to be much more common than they thought and have to “find a place for it” on the main page or screen instead of arranging everything to better suit the need. Both get sent back to make fixes, engineers when they find a new bug, and designers when usability testing proves them completely wrong about something. And once a product ships, whether a problem is a functionality bug or a usability issue, it’s that much more painful.

I’d like to think that Computer Science projects I’ve worked on in the past have been easy to use, but if so it’s only because I’ve always thought about software features in terms of where they go on my screen, how close they are to my mouse, and where the go on my whiteboard picture of the application window, which is what I would tend to start with. Whatever you’re more passionate about, that’s what you’ll spend the most time on. In my case, I love starting with a big drawing of what my application is going to look like, and then spending a long time coming up with huge class diagrams for the code. I like the design parts of both sides, and then I always wish I could be doing more design by the time I need to start writing the code.

I guess the best way to make open-source projects more usable is to get people who passionately love to draw pictures of applications and create scenarios and information architectures to work just as fervently as the developers who passionately solve engineering problems to get what they want. As many open-source projects should originate from HCI people as originate from hardcore developers, and people can share projects and continue to work on open-source software for the same reason as always: because they get to do more of what they love.

Comments are closed.