Having held both design and development roles, sometimes at once, on application software and user experience projects, it’s clear that notwithstanding the advent of the agile environment, there remain aspects of designing and building software that aren’t understood well in roles that are not responsible for certain parts of the work. That shouldn’t be a problem, one would hope that everybody on the team could do their respective work, wake up one day when the work was finished, hit the button and it all comes seamlessly to life. Right? Yeah! Well, maybe not.
Few would argue that the process and thinking of design are different than that of development and engineering. Those people I know who are in either role and do well working with people in the other role tend to be self-aware, and able to understand how different they are from each other, to an extent that they have inquired about others’ roles with genuine curiosity.
For those who are mystified to any degree, perhaps viewing the two roles as having a complementary nature can help to shed light on what is significant to each.
If the complementary nature of human consciousness is a bit unfamiliar, an excellent book has been written to illustrate how these two modes work together framed as archetypes. “Solar Light, Lunar Light: Perspectives in Human Consciousness” by author Dr. Howard Teich is available on Amazon.com, ISBN-10 1926975057.
Complementary Consciousness Is Binary
As Dr. Teich points out in his book, part of this complementary nature is that you can’t function in both modes of consciousness at once, it’s either one or the other. When operating in one mode, especially if that’s how you function most of the time, you won’t easily see the nature of the other mode in progress or identify how it manifest results. In addition, if you’re more comfortable in one mode, as most of us are, you will be likely to have challenges functioning in or relating to the other mode.
When I am at work on a project that requires both design and development, as much as I would like, I cannot hold what feels like the open, ever evolving view of design vision throughout the entire development cycle as I’m writing out classes and choosing logical constructs to build functionality. At some point, I have to drop anchor on the design and shift to completing the concrete tasks of building out the work.
During design, I’m thinking about what emotions I want to evoke from people when they’re using the product, the emotional conveyance of the visual elements as well as the interactive timing, and are the features cogent. I’m assessing whether the functionality is elastic in serving divergent interests, whether the design feels smart and credible, and does the user experience cue the user at the appropriate moments.
When writing code, my focus is different. Structure is built in to the nature of any programming language. I place a significant priority on efficiency, structural integrity, and that the way the code works matches with what is expected. Efficient code is often elegant to read, and you can tell when well written code runs smoothly and fast. But the code looking and feeling good is subordinate to the set of rules that produce elegant code. It’s more about creating the appropriate mechanisms, adhering to structure, and thinking my way through the process. I do, at times, direct a high level of creative thinking toward finding a means within the structure to accomplish what I need without violating structural integrity. My effort is bounded by structure. In fact, I will go to great lengths to learn how to code a feature so that I can depend on the structure to support the visual and interactive innovation I want to use.
Distinguishing Solar From Lunar
While engineers can easily relate to the Solar archetype described in Dr. Teich’s writing, I’ve found it less common among engineers to have insight into the Lunar process which is primarily my frame of mind when designing motion graphics, user interaction, wire frames, photography, painting and drawing.
One of the best metaphors in the code we’re writing these days that illustrates a distinction between these two modes of consciousness, and is representative of the confounding nature of my design process to someone who doesn’t easily visualize artwork, are the twin concepts of synchronous and asynchronous programming.
Synchronous operations are sequential, hierarchical, and discreet with clear cut bounds – nothing goes forward until x happens. By contrast, an asynchronous operation is designed to proceed independently of other operations moving forward. Asynchronous code does have dependencies, but it’s core similarity with Lunar consciousness is that different pieces of work can emerge at different times. All the pieces add up to the whole, and you don’t know when each is going to fall into place, you just learn to recognize that everything has come together when the design starts to pop, it feels polished, and the list of refinements is a set of tweaks rather than features.
The Patience To Allow Design To Emerge
At the outset of a design project I detach preconceptions about how the design should look based on other metaphors, and instead seek to draw fresh imagery or words that resonate with the spirit of what the user might intend to accomplish and also align with targeted user profiles. I may cycle through several attempts before I get a hit that feels credible. This list is always longer than I want it to be, but I persist because I believe there is a ‘yes’ at the end which serves as a fertile kernel we can return to and refine.
On user experience designs I start with a core element or process, and move to another area of the design when I exhaust changes I want to make with the piece I’m on, whether it’s finished or not. As the work progresses, different segments emerge which have dependencies on other parts, and they build up and stop until others catch up. Starting out is never easy because we’re starting from nothing. As the build up accumulates, getting closer to critical mass, the reassurance builds that the process is working as anticipated because completion begins to become evident.
This result emerges every time, and I don’t spend time or energy agonizing over elements that aren’t coming into view. I know this process produces excellent results, and does so with an efficient timeline.
On a user interface project, there is almost always one core pathway that has the most value to the user to accomplish, and is also the strongest offering of the software. I call this the golden highway because every other process or feature has to serve this accomplishment. Whether enhancing it for a particular user profile, earning engagement by connecting it to an up-sell revenue stream or anchoring the application to a broader foundation of usage.
Timing motion graphics can be meticulous, until the whole piece starts to flow and, as in the ux process above, there’s nothing left to change. Completion often takes me by surprise and I recognize that the work is finished if I set it aside for a couple of hours, go back to it, and still find there’s nothing left to change. I do this because I know that after a certain period of time working on refinements, my eye becomes inured to what may have stood out as a problem earlier. Working on something else for a couple of hours and then returning to play through the animation again, I may see something that could be improved that I didn’t see before. Allowing the voice of the design to emerge is critical to qualities of freshness and fluidity in the finished sequence.
Productive Software Teams Balance Both Solar And Lunar Consciousness
The design process I’ve just described is actually a mix of solar and lunar constructs. I’m most at ease with working in lunar consciousness, setting aside preconception, starting from nothing, and patiently refining whatever shows up in the void, trusting it will all come together at some point. If it makes you uncomfortable (at best) to see yourself working this way, that may be because your work style is solar to a greater degree, and therein lies a very important key to constructing innovative results. A well balance team will have both.
There are processes that have to be in place during construction, and after a software product is designed, released, and in use by large numbers of users which feel extremely confining for me to work on. This is not a problem, because most of them are not involved with design or refining a user experience. I don’t engage working within those processes, but knowing what they are, and being able to relate to why they need to be locked down is highly significant to integrating my work into the whole, and I’m well aware how important it is for each to be able to serve the other’s requirements.