Article summary
I chose to use this stock photo in an effort to visually represent this concept at a high-level. It does not represent actual project code or structure I would go about in my own work.
Designing a whole product experience requires fully understanding your constraints and being able to validate the final outcome of your choices. When you’re creating software, both constraints and validation can be wrapped up in technology and code. Can software designers really make the best possible decisions if they don’t fully understand the technical ramifications of what they’re doing? I don’t think they can.
I was recently considering this idea after participating in an AIGA West Michigan roundtable on the topic of designers & coding. Specifically, the question was around how much coding designers should be doing.
Over the past few years, I’ve been doing more and more coding, and it’s been a very positive experience. Here are the top 4 things I took away from it.
1. Code helps us understand our medium.
You don’t need to learn all the theory; lean on developers for that. You do need to know what technology is capable of and how to best modify your designs to adapt. Understanding constraints and limitations of each operating system and platform is necessary to design the most optimal and feasible user experience.
Working at a consultancy, we are constantly faced with decisions around other business constraints, like timelines, resources and budget. These weigh heavily into design and implementation decision-making on how best to spend time and how complex to make certain features. This helps keep scope in check and keep designers from diverging too far on any one task.
2. Code lets us prototype more effectively.
Prototyping with web technologies can serve as one of the most valuable artifacts that can be shared across teams. Regardless of the final medium, I use this technique to mockup high-fidelity prototypes to simulate the proposed design solution. This becomes a central artifact for the team internally and externally. It allows the client to get a feel for an idea without investing in production code. I use this to gain consensus during iteration meetings, as well providing an easy platform for peer reviews. When there are multiple concepts at play, it can be hard to keep track of where final decisions were made. Having a hosted prototype maintains a central artifact for all decisions made to date, all team members can access this as they are working through the design and execution phases.
Prototypes are valuable in many ways, and often don’t get utilized early enough in the design process to gain consensus with the client and users on how a proposed design might fit their needs. We use prototypes to simulate the end user experience when conducting usability tests. The earlier you can get something out and tested, the more time you’ll have to iterate on the design and pay attention to rich interactions.
For any digital or software interface, the ideal process would be to start creating a high-fidelity prototype early, even if you haven’t applied the visual design. If possible, I will code with CSS/HTML/JS. Depending on the interactions and workflows I need to test, I’ll incorporate some static artifacts to create the illusion of a finished product. Stitching together high-level pages at minimum allows you to address other details like navigation design, hover states and transitions. I find that even if you can shortcut the prototype, coding moderates the design process to really edit and make careful choices as you evolve your design. I discover a new understanding of how to design for implementation and can edit on the fly, rather than updating a static mockup.
3. Code brings designers & developers together.
Working with code gives me empathy for developers. I start to think in terms of how I can incorporate a transition with CSS or JS and can begin to speak a common language when doing feasibility checks with my developer. Learning enough of the tech vocabulary will go lengths to developing a shared understanding with your peers. For example, when iOS developers talk about storyboards, they might mean something completely different to a designer unaware of the Xcode application. Developers on your team will want to know about your design process and work patterns. Developing a shared language early on will lead to a greater product in the end. It is ideal to build these feedback loops into your internal process as a way to ensure quality and consistency when delivering new releases to your client.
A company’s culture will highly influence how designers and developers work together, and even which holistic practices they use to execute digital products. There is no better circumstance than to have designers and developers co-located. It’s important to set an agreement early on how best to communicate throughout the project, and by which workflows you will collaborate. With the design hand-off there are many risks associated. Designers should not toss the work over the wall without stewarding and providing continuous feedback toward the quality of ongoing implementation. If a prototype is created, the developer can access this as the designer moves onto their next feature.
4. Code is the central language in agile software development.
Within an agile software environment, an understanding and ability (to some extent) of code is mandatory. Culture must support experimentation and flexibility in process and practices. With integrated design and development teams, we like to find common ground in practice. This is a platform in which translation can occur. We don’t want to annotate paper mockups for developers, we need to produce the front-end to some extent.
Within our iteration cycles, we get prototypes in front of users in order to validation previous design decisions and shed light on improvements that need to be made to the design. Shorter, continuous feedback loops with the client and users will maintain convergence to a finished product that everyone feels a shared sense of contribution. Prototypes come in many forms, it’s good to know what method and level of fidelity is right for the problem you are seeking to solve. Getting the whole team involved with observational testing will build confidence the team is working toward the right vision. The prototype becomes the bridge that allows the whole team to get a sense for the end product experience in time to make some critical changes.
Dare to code, but don’t let it constrain you.
If I could offer any advice outside of what has been mentioned above, is to not be afraid of code. There are many tools out there that make it easy for designers to get by without coding, but you miss out on greater opportunities to connect with the medium of your end product.
It’s best to know which tool is right for the job. For example, using InVision for low-fi prototypes is a great way to gain consensus on high-level workflow and visual design. Using Squarespace is perfect for getting a sophisticated site out quick, which I would recommend for an online portfolio or micro site.
Don’t let your tools paralyze your ability to design; they should be an extension and provide opportunity to take your designs further. Awareness is key, and if you cannot adapt your designs in a way that intuitively translates to developers or the product platform, you will fail to implement a successful product. For those looking to build a knowledge of design and coding, visit Treehouse.