Designing for developers – Pixel pushers and code crunchers unite!

Designing for developers. Some might say the two are a different breed, but in my experience there is one thing we will always have in common – the hunger for perfection. Sometimes we may see perfection in a different light, or even at the total opposite ends of the spectrum. However, ultimately, we usually share the same goals – to create something great, change people’s lives and make the world a better place.

As a seasoned designer, I have had the opportunity to work alongside many developers in a variety of environments, from design agencies to high-tech software companies. The amount of interaction I have with developers always seems to change in each role, however, one thing always remains the same. If you don’t work together like a well-oiled machine then the project will suffer and, ultimately, what you end up shipping will reflect this. So whether you are a pixel pusher or a code cruncher, these tips will hopefully help your working relationship run that little bit smoother.

Avoid the dreaded Bottleneck when designing for developers

During the initial discovery phase of a project it’s important that you have both the designer and developer involved in some capacity. This is the perfect opportunity to workshop ideas, drawing from a wealth of experiences and perspectives – whether it’s creative ways of presenting content or the technology in which these ideas will rely on. Avoid that dreaded bottleneck of information and get the team across it all earlier rather than later.

Get your developers on board with UX

UX (User Experience) Research & Design. It’s an immense topic and something we don’t really need to dive into, however I would like to touch on a few areas where a little effort will go a long way when bridging the gap between design and development.

IA

IA (information architecture) focuses on organizing, structuring, and labeling content in an effective and sustainable way. The goal is to help users find information and complete tasks. Traditionally architects work with tools such as site maps, process flows and wireframes to plan and illustrate structure, inventory, content flow and navigation. As a designer who spends a lot of my time in this area, I find it valuable to get the developer’s input before I deliver the IA resources to the team or client. You can workshop ideas around the delivery of content, search functionality, navigation and content management from a design and technical point of view. You can validate design ideas and eliminate any early scope creep. These IA resources also act as a stable reference point for all of the team throughout the development process. I have also found that the wireframes are a great resource for the developers to reference throughout the development process, rather than just relying on high-fidelity mockups to communicate all of my design thinking.

Personas

Personas are archetypes built to identify our real users profile, needs, wants and expectations in order to design and develop the best possible experience for them. Personas are not just a tool for designers and information architects. In my experience personas tend to be ignored by Developers, so to ensure this valuable research reaches the wider team I tend to pin up print-outs around the office to constantly remind the team who we are designing for. It also acts as a great reference point to back any decisions made throughout the design and development process.

Embrace Agile

I can honestly say that my experience with Agile has been extremely positive. I see the Agile methodology as a fantastic tool belt of processes that ensure designers and developers are always on the same page and aiming for the same targets. It promotes collaboration and iteration, two things that I believe are crucial when working on larger projects.

Early in my career I would simply hand off designs to a developer, give them a quick brief on the project and we would go our separate ways. I would rely on my designs to translate all of the knowledge I had gained in the initial discovery and planning stages. Further on down the line the client would be presented with the final solution and usually the developer and project manager would end up cleaning up the mess that could have been avoided if we had worked closer together throughout the development phase. Agile has proven to be a great way to keep things transparent and iterative between myself and the developer. The developer is involved from the start and we are encouraged to work alongside each other rather than independently. This ensures vital conversations are had earlier rather than later, and there are no surprises and re-work for anyone down the track.

Get under the bonnet!

As a designer I tend to wear two hats. One hat for IA and design, and one for front-end development. I believe it is imperative that a designer finds the time to upskill in the area of front-end development, even if it’s not part of their role on paper. This will ensure that they have a good understanding of the mechanics behind the final environment they are designing for and can then make more educated design decisions throughout the entire design process.

If I’m not part of the HTML build stage, it’s important that I can provide a developer with all of the resources required to build a website or application. I don’t expect them to have to make design decisions. For me, having knowledge in the area of HTML, CSS and JavaScript, enables me to easily bridge the gap between design and development, and ultimately avoid any unnecessary back and forth between myself and the developer down the track.

Validate your ideas

Some designers tend to propose functionality without actually investing time in understanding what is involved with developing it. The functionality may prove to be a lot more complex than originally thought, and may affect existing technologies that are already in place. In some cases there may also be existing code in the system that can be reused to achieve the same results. The last thing that you want are multiple conflicting scripts, frameworks and stylesheets that bloat your site or application. My rule of thumb is always research your ideas so as to validate your designs, or at least run them by a few developers to get a more granular insight.

Make, break and repeat

Understanding the theory behind responsive websites, web and mobile applications is all very well, however a more practical understanding is also required to do the job properly. Build a responsive page or app screen from scratch or at least pull apart a framework such as Zurb Foundation to see how it all works. Experiment with your code across multiple devices to see how it renders. Be adventurous and throw some media queries in there. Break things so you can then fix them. Get your hands dirty!!

Top 12 tips for designing for developers

Tip #1: Always design with layout grids

This will ensure your content is organized and is laid out consistently across multiple screen sizes. The grids in your design software should correspond to the grids a developer uses to markup the HTML. Design software such as Sketch come with fantastic modern preset layouts and grids. You can also generate grids yourself with free online applications such as gridpak.com. You can then download the PNG for your design software, as well as the associated CSS, SCSS, LESS and JavaScript for the developer. This makes for a speedy transition from design to development.

Tip #2: Design with Increments

An increment is a measurement used to determine the size and position of elements on an app or webpage. This not only helps the designer layout their page pixel perfect, it also makes it easier for the developer to layout the design as HTML. A great example of increments in design can be seen here with Google Material.

Tip #3 Offload designs using collaboration tools

Gone are the days where a developer would have to open up a designer’s bloated Photoshop or Illustrator file and painfully go through each layer to access assets and measure page elements. These day’s we have fantastic collaboration tools such as Zeplin that allow designers to quickly export their designs to a centralised app accessible by the entire development team. Included with the design mockups is information such as sizes, colors and margin. Sometimes the information provided is all the developer will need to translate the design perfectly. The tool also proves to be a great way to communicate with the team. Zeplin is available for design software such as Photoshop and Sketch.

Tip #4 Design with reusability in mind

In an effort to provide an optimal experience to users, designers should always focus on the consistent treatment of design across their website or app. This approach will ultimately then extend to reusable code, CSS and generally boost productivity for future development. When there is less CSS and scripts then our users will receive faster page loads and an overall better experience.

Tip #5 Provide visual style guides

These are resources you provide your developer to quickly reference common styles used throughout the designs. Visual style guides can be as simple or complex as you want them to be. They can simply be static mockups or snippets of HTML and CSS. When I design a website or app I tend to mock up a separate page that includes only typography styles and the metrics that surround each element. I will also create separate resources that focus purely on navigation, color, button states, data tables etc. Separating these design elements from the overall mockup sometimes makes it easier for the developer to set the common styles before they start writing custom styles.  

Tip #6 Provide interactive guides

As per the visual style guides, I find it useful to mockup up visuals that illustrate how I see the user interacting with features in my design. An example would be how a user navigates through an app with swipe and pinch gestures, or how a draggable shop cart works across different screen sizes.

Tip #7 Get smarter with color palettes

Color is a science and something designers are obviously passionate about. However, in my experience developers will give less attention to whether that blue in the mockup is a hex value of #0277BD or a slight shift to #0378BE. That slight shift in color may just be the one thing that confuses a user when performing an action on a website or app.

Providing the developer with a color palette with associated hex values will save a lot of time and will act as a useful reference point for the entire team. It will also make it easier when a developer comes to create a CSS or SASS document with all of the common colors.

Google provide an extremely useful resource. The color pallette for their material design. You can also download and import the color pallette into design software like Sketch as well as browsers and developer tools.

Tip #8 Design in vector and export as SVG

SVG (scalable vector graphics) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. An SVG can be manipulated directly in the code so it makes for a great format to pass through to developers.

Tip #9 Use online prototyping tools

Developers will always need some way to reference a designers mockups as they build websites or apps. It’s also useful to be able to interact with the mockups and experience how a user should be able to navigate through each page. If there are iterations to the design then these online mockups can be quickly updated in one central point. Thankfully there are some amazing free online tools that will allow us to do all of the above and much much more. Our design and development team currently use Invision as a prototyping, presentation and collaboration tool. We swear by it. Another great online prototyping tool is Marvel.

Tip #10 Provide process flow diagrams

Process flows are usually a resource that is created earlier in the IA phase rather than the visual design phase. However, I find basic mockups at any stage of development is a useful tool to communicate ideas to the developer.

Tip #11 Design with real content and data

Rather than designing high-fidelity mockups using placeholder text, it makes more sense to base your design around real data and content scenarios. The developer should not have to address these challenges further down the track.

Tip #12 Always keep the lines of communication open

I believe it’s important to keep dialogue going with developers throughout a project. It does not have to be a major review of work each day, but more of a quick update each day of progress. At this stage you may find that the developer is missing assets or needs clarification around the design thinking. It’s also a great  way to keep up with the latest Game of Thrones.

Conclusion

So to sum it all up…I believe designing for developers is all about forward thinking. Working together earlier on and providing each other with knowledge and resources throughout the process to support each other’s work. Designers who invest time in researching technologies and upskilling themselves in front-end development tend to make smarter design decisions that will ultimately avoid any re-work once it’s in the developer’s hands. And lastly, don’t just hand-off and move on. Work with your developer and see the design through to the end. Organise regular reviews and adopt some kind of process from the Agile methodology. At the end of the day, when that app, product or website goes live, you can both sit back and feel proud of what you have created.

The Author Wayne Bowman is a Digital Designer at Raygun.com who build error and crash reporting software and real user monitoring tools for software teams. He is also a mean ten-pin bowler.