You are currently browsing the monthly archive for April 2008.
I’ve started writing about the differences between programming and designing for an application, cataloging the challenges and differences between the two, and how to manage both worlds from both the perspective of a manager and a worker. Because this has become fairly long, I’m posting it in parts in what so far looks like it’ll be a 2 or 3 part series on programming and design.
Programming is absolute; it’s about results. Designing is proportional; it’s about interactions. I do and have done both types of work for years, so I’m well aware of the challenges in each. Switching between a functional programming task and user interface design task, though, is like trying to play two different sports at the same time. It’s very taxing and mentally fatiguing even if you enjoy both individually.
Because of my experience, I’m well aware of the differences between each. Additionally, as the engineering and design team manager, I know what to expect from different types of people, and I experience the IT axiom that programmers make bad designers (and designers can’t code) on a daily basis. However, it’s not really anyone’s fault. It’s inherently different work, but there are methods for smoothing over the development process between these two worlds, so let me describe both worlds, how they’re different, and what you can do in smoothing over the interaction between each. Smoothing over the rough spots will make work easier, but also increase job happiness as it’s more fun for people when they’re in a groove, and really able to focus and excel at what they enjoy doing most.
The Binary Stroke
Programming is like traveling. You have a task that requires you to get from point A to point B. There are many possible roads, some better than others, some more interesting than others, and some with more existing infrastructure. There’s a predetermined destination (although not always well known or understood), and a set starting point. What you do in between, how you get to point B, is up to you.
However, as with any problem, there are always conflicting values that require compromise. In programming, you typically resolve conflicts between performance and process. You need to make a function that is fast enough, but handles many variables and lots of data at the same time. The more variables and more data, the more processing, the longer it takes. Or you might be fighting with memory and disk space (typically because of performance requirements) where memory is faster, but because there’s much less of it, it’s more valuable and easily consumed, and disk space is abundant, but slower.
Of course, you also can’t forget that in the real world there’s always an conflict with time. You might have to cut back on overall functionality in order to make deadlines and deliverables. You might not have time for all the polishing and perfecting that you’d like. Or possibly, everything else gets pushed back until you’re truly ready. Time can turn even a simple problem into a rough and raging Nile River.
Dealing with those kinds of problems is like coming to a river without an obvious crossing. You can search along the river for an existing bridge (search for solutions to this or similar problems by others), or find a low spot for easier forging (pick the low hanging fruit and find a way of solving the bare minimum as quickly as possible). You can build your own bridge for more appropriate crossing (write code that’s reusable with potential long-term returns), try a simply rope line (quick hack), or a setup a wooden foot bridge (non-reusable, but maintainable solution). Still at the end of the day, you know if you’re on the other side or not, and you know that you’re at a river when you come to it.
A good programmer will spend her time learning about coding principles and techniques. She’ll have an interest in new technologies that are just interesting in themselves, or useful in her own work like a new and helpful open source reporting package. She’ll try and stay up to date on changes in tools and emerging concepts while making sure the app server or JDK that you’re using isn’t totally out of date. And generally, she’ll enjoy geeking out with most anything technology.
Shining a Spotlight in Dark Alleys
If programming is like traveling, and problems are rivers and solutions are bridges, then design is like being a cop, and problems are criminals and solutions are tickets. Keeping the peace is a matter of keeping unruly people in line (fixing bad layouts and user interactions), and building relationships within a community that strengthens that community (setting up look and feel standards that enhance the important messages while still functioning in the face of conflicting messages). However, you’re not the judge or the jury (someone else will eventually tell you if it looks good and feels right). You’re given a list of potential crimes and criminals, and you enforce them based on the rules of the system.
Compromise is a given as a designer. If you think you can become a designer and be as creative as you like and call it a day, then those with the message (and the paycheck) will quickly set you straight on what your boundaries really are. A designer’s job is that of appropriately, consistently, and clearly getting a message out; someone else’s message normally. And when it’s someone else’s message, then it’s their ability to be creative or accept creativity that limits your work.
The most important concept in design and usability, and where true conflict occurs, is consistency. As I said earlier, design is proportional and about relationships and interactions. In code, you can break an application by setting a variable equal to 2 instead of 1. In design, changing the color of a button doesn’t break the application, but it could build inconsistency. Sometimes, in the right special cases, inconsistency enhances the message and design. In most cases, inconsistency harms the design, but you don’t feel the effects until you reach a breaking point.
One visual element interactions with all other visual elements. The more inconsistency, the more visual conflict. Our brains can deal with a lot of inconsistent design, bad layouts and interactions. However, it builds up proportionally, so a designer has a margin of error to work with, but there is a breaking point, and in all designs there will be conflicting messages on a page. A designer must find a way of enforcing the rules of the system and getting the unruly elements to still work together nicely. What most people don’t understand about design is that while one change is minor, 5 minor changes huge overall impact. This is even more challenging if you’re designing an application that has hundreds of interactions across multiple pages. Keeping cross page interactions and designs consistent is as important as single page consistency where changes on a single page actually effect the whole of the application.
A good designer will spend her time learning about design principles and new techniques for enhancing a process (like how to improve a signup form). She’ll have an interest in new, compelling, and provocative design. Some of it may immediately help in her daily job, but most of it will probably help indirectly by association as much as practical application. Still, she’ll have a desire for turning the good design she sees into something applicable to her own job, and not just depend on osmosis for her education and career improvement. She’ll have an interest in the latest trends (and historic trends) as a way of keeping designs culturally relevant while still being exploratory in what she does.
Waiting for more
This may be an abrupt ending. I’ve basically cut this first part out of a longer piece for ease of internet reading, but this topic will continue shortly in part 2.