Jerry is a user experience designer at Atlassian working with the Atlassian Marketplace team. This is his first post on our dev blog, about his experiences trying to enter the code base and, in doing so, learning a little about how our customers — engineers — think.
For years designers have lived outside the code, relegated to the realm of Adobe Photoshop and Illustrator. Being satisfied with graphic design programs in this modern age, however, can be hazardous to your health. Problematic UIs and convoluted work-arounds must be used in Adobe for simple tasks such as a pixel-perfect circle. Modifying positioning or groups of elements can be painfully slow. It can be impossible to judge elements against each other in any fast or meaningful way. While Fireworks alleviates some of these problems, and other tools have and may still surface, many graphic artifacts remain in the legacy formats, and don’t lend themselves to easy transition. Many designers do not want to learn new, inscrutable interfaces.
Even if you have carefully considered theses facts, graphic artifacts still require additional translation: from designer to developer, from developer to code. What may be easy to mock-up in a design may take a good deal of back-end work or have limitations unknown to someone solely in a world of graphics. If something goes wrong in any part of the translation, as is often the case, the process of fixing a mistake can be arduous. Ironically, it is often the small fixes that are hardest to justify due to the disproportionate amount of time investment to reward: filing issues with your resident issue tracker, branching, pulling, pushing, reviewing, blitzing, etc ad infinitum. Teams move on… the designer cannot. S/he files issues sadly, watching them pile-up of in an intimidating, mountainous backlog, unable to effect change, growing sad and bitter.
Enter the Code
Perhaps the solution, uncomfortable as it may be, is to enter the code. As a user experience designer working with the small but dedicated Atlassian Marketplace team, I thought I might take my own stab at getting in the code. I had worked with html/css in a rote way in the past for some independent development, but had little idea of CSS3 advancements, the build set-up at Atlassian, or of useful development tools. The last time I coded I had been using an outdated copy of Adobe Dreamweaver, pushing code directly to the server. To start developing again, given the caliber of developers at Atlassian, seemed an unlikely, potentially dangerous, proposition.
I was learning not only about the difficulties and challenges of making what I saw as small changes, but the possibility of wider-scale changes I had precluded in my mind. I was learning about the process it takes for a small change: a ticket, a branch, a pull, a review, a push… end-to-end dogfooding on Atlassian products. I was getting first-hand experience with our tools from the eyes of our users. This experience made me realize the possibilites of our tools to do so much more: tracking coherently my work for the week, finding spaces for my own personal projects. Most importantly, I was learning to talk intelligently with the individuals who were actually building, brick by brick, the designs that I had developed.
You can get involved
Getting started can be the most difficult part of entering the code, simply because of the amount of effort required to get you up and running with a company build set-up or the background intricacies of the code. To this end, the support of your team essential. Finding pieces of time and developing a good rapport goes a long way when you need advice about a git disaster, or want to pair with someone when you accidentally find yourself in harder areas of the code.
Don’t be afraid to make the case for yourself: teams for the foreseeable future are faced with a lack of front-end help, in addition to an overwhelming need and drive to beautify and fix ux issues. Acknowledging your own limitations and starting small also goes a long way to reassure individuals you’re not going to blow up all the things. Learning and following code conventions, following processes and diligently responding to code reviews. Studying up on git and refining your knowledge with free classes such as codecademy, while indulging in design-development unified blogs such as Smashing Magazine, will help fulfill both your desires.
Not for everyone?
The obligatory caveat section: development is certainly not for everyone. Though the experience and knowledge gained can benefit anyone, conditions for you entering the code may vary. On the Marketplace team, I’m uniquely fortunate to be working with a relatively new, agile product… your own codebase may be restricted and complicated by legacy issues. Again, be wary to test and ask for reviews, lest you introduce a hidden bomb for later, more savvy developers.
For the truly gifted graphic creators, I’m strongly in favor of specialization: for some, the greatest good is to create the beautiful graphics, backgrounds, textures that adorn our soon-to-be-beautiful products (e.g. our resident BitBucket designer, Joel Unger’s, Ship-It Day project). In many ways, I’d prefer for them to to be sandboxed into the world of vectors, 3-d and iconography, looking to the more multiple-hat type of designer to get involved with the design+code implications.
Entering into the code can be dangerous if one falls victim to code-mind: “We can’t do that, it’s too complicated.” The broad-minded designer that enters the code must check themselves carefully not to limit designs too far based on the perceived time or difficulty. This is a fine line, walked carefully between time and talent, needs and desires for the perfectly designed application.
Perhaps most importantly, design and development should not start by jumping into the code. The end-to-end experience is the job of a designer, first and foremost, which means sketching, stakeholder interviews, usability tests, contextual inquiry, comparative analysis, card sorts, and a slew of other research methodologies before even beginning to layout a screen. For big redesigns, the designer should abstain from the code and focus on making the journey for a customer seamless and delightful..
As should be clear, learning and involving yourself in the code has long-lasting benefits, not only in refining your product, but broadening your design understanding, speeding up your workflow, and refining your understanding of colleagues’ trials, tribulations and triumphs. As the Atlassian Product Design Language slowly rolls out, knowing and attempting to get into the code will be more invaluable as the Atlassian User Interface codebase allow for quick mock-ups in the new style.
Remember: With great power comes with great responsibility. In my experience, however, the risk is worth the reward.