I’m a mobile designer on a team that ships apps. When crunch time comes around and developers are working hard to make sure every pixel is in the right place, what can I do to contribute to the final product?
Drop new image assets and interaction notes on a developer’s desk and wipe my hands of the issue? Do I need to specify exactly where those images need to appear at all screen sizes? Do I define those coordinates in pixels or points or device independent pixels? What should I name the assets? Doesn’t the developer already have a backlog of other issues to work on? If designers have a seat at the table, why don’t we get our hands dirty and contribute those assets directly to the project? As a designer, writing code is not my area of expertise. But I can be a better mobile designer and take ownership of my work by learning how to do a few simple tasks in the tools developers use.
At stable|kernel, we use Git for source control and host our projects on GitHub. We use Xcode for iOS development and Android Studio for Android development. These tools require some setup to get the environment just right for your project, but developers have always been happy to guide me through this process, especially given the scenario outlined above. Once those tools are set up and the project is cloned to my machine, I have the same power to affect change in the app that a developer does. That newfound power can be scary and paralyzing to a designer, but it’s important to remember that tools like Git are meant to reduce the impact of negative change on a project.
Before I start wielding this power to make changes, I use Git to make sure I’m working on the most up-to-date version of the project. We use the command-line to interface with Git, so I open terminal.app, navigate to the local project folder on my machine, and type in:
git checkout master git pull
This pulls down the current master branch of the project. At stable|kernel, all changes must be peer reviewed before being merged into the master branch, so my next step is to create a new branch for my changes and push it to the remote GitHub server. I can do that by typing:
git checkout -b bh/new_assets git push -u origin bh/new_assets
In this case, I’ve followed our format for naming new branches by using my initials (“bh”) followed by a slash and the reason I’m creating the branch (“new_assets”).
Now I’m ready to open the project and start making changes. For this example, I’ll update some image assets for an iOS project. First, I open up the .xcodeproject file and select the asset catalog (*.xcassets) using the Project Navigator in the left sidebar. Asset Catalogs help organize images for different densities and form factors. Next, I’ll select the image set that I want to update and drag-and-drop the updated image assets into Xcode. To keep things simple, I keep the filenames consistent to avoid having to change any references in the code.
Let’s back up for a second and say I had simply attached those new image assets to an email and sent them to a developer to implement. How long will it take to verify those new assets look right in the app? I would have to wait until the next build gets sent out (which could be days or weeks), download it on a device, and check the assets. If those new assets have alignment/sizing issues, I would have to guess what’s wrong with the assets and start the whole cycle again. By implementing those assets directly in Xcode, a designer can short-circuit that iteration cycle and test those new assets immediately by building and running the updated project in the Xcode Simulator. Even if a designer isn’t editing asset catalogs, XIB files, or code, testing builds is part of the job description.
Now that I’ve verified everything looks good (on all targeted devices), I go back to the command-line and commit my work. I can do that by typing:
git commit -am “Here’s what I did” git push
At this point, I’ve pushed my changes to the remote GitHub server. In order for my changes to become part of the master branch of the project, I need to submit a pull request on GitHub. This lets my team know that my work is ready to be reviewed. Once another set of eyes approves the changes, my branch can be merged into the master branch and deleted. Now that the new images are on the master branch, I can say that I’ve officially contributed to the project as a designer!
This may seem like a long process to update a couple images, but after going through the process a few times it becomes second nature. Designers can handle managing linked smart objects or manipulating bezier curves with the pen tool. We can certainly handle typing six commands in the command-line and dragging some files into Xcode. Plus it saves developer time, minimizes the delay between testing cycles, and empowers designers to control how their vision is presented in the final product.
Opening the door to development is a scary thing for designers. With the help of my fellow developers, I’ve become increasingly comfortable with an arcane command-line interface and the abstractions of code. I know I cannot possibly harness all the potential power of development, nor is it my role. But by truly collaborating with developers, inside the same toolset, we can create better things together.