Compare and Contrast – A Technique for Better Specs


By providing compare and contrast opportunities in our specs, we are infusing ux into the ux/ui hand-off experience.

When we are in the process of providing specs for a product enhancement, the developers are already familiar with the product (assuming they built the original product).

Since they are familiar with the current product, it facilitates their cognitive comprehension of the desired changes if we provide them with a compare and contrast spec that is annotated. The result being that we are working with their current mental model and then gently ushering them into the new design. The annotations help quickly identify the differences. And the side-by-side presentation allows them to

  1. not work from memory, and
  2. be able to quickly identify the differences visually.

Compare and contrast is a teaching strategy employed at all levels of curriculum, since it’s so effective at scaffolding knowledge. By bringing this technique into software development, we can make the process more delightful for everybody involved – especially the engineering staff that needs to interpret the specifications. But similarly for stake holders that need to understand and sign off on designs before they get moved to the development stage.

Since employing this technique in my specs, I find that there is much less back-and-fourth, much less “mansplaining” and simply a lot more calm around the design handoff process. If you haven’t tried it yet, I strongly suggest you do.

Working with Offshore Mobile Developers – It’s Awesome

For the past several months, I’ve been creating a product using freelance developers on Upwork – and it’s been fantastic. Currently, I have branches of my iOS app being built by 3 different mobile developers – including a woman from Hong Kong, a gentleman from Ukraine, and another from Germany. In addition, a developer in Pakistan hops on Skype calls with me to help me evaluate project timelines and committed repo builds.

Why am I working with several developers and not just one? It all started from a place of fear. I was afraid of theft – that some developer in a far off land would steal my product, repackage it, and launch it on their own. Well, those fears haven’t completed dissipated. I’m still very cautious when entering into a new working relationship. Two of these guys have been with me since day 1, and it’s gotten to the point where I trust them implicitly with my code base – and also in terms of cost/invoicing.

But here is how I approach working with a new developer: I give them a blank, private repo on Github, and ask them to commit their work to it. In these cases, the work has not been dependent on the entire code base. Thus, they could work in this silo. For example, in 1 round we just focused on the layout and interactions of 1 screen in the app – no back end was required. In another case, where a backend was required, I mocked up a “faux app”.

Part 2, The “faux app” process

My app requires a login flow that allows the user to “skip to browse”. When they are in browse mode, they can’t create certain actions – and they can’t observe certain user-protected screens. In order to hide the entirety of my project, and simply build a working relationship with a new developer, I created a simple, simple app – I title this the “YesNo App”. And here I emphasized with the developer that this entire iteration was about the user experience of the log in and sign up process – including all the error messaging that accompanies such a process – in particular, errors related to duplicate account creation when a user authenticates using Facebook, and then tries to authenticate once again with that same email address.

There were moments where the developer was incomprehensible about what I was asking them to develop – the app was so ugly, didn’t I want him to him make it prettier? My answer – “absolutely not. Pretty is completely irrelevant for this build. It’s all about the tech that goes into making these flows great. If we can execute the tech properly, then we’ll discuss the visual design.”

In the end, the developer coded this entire build without ever knowing what my final app would look and work like – only how the login & sign up flow would feel like – and the flow of being logged in or logged out of my faux app.

Attached is 1 of the specs I provided my developer. YesNo Prototype – Messaging, Flow, Experience

Lastly, I should mention, he needed to build out an MBaaS for this faux app to work. He did so in Parse, then simply transferred ownership of that Parse app to me when the project was completed.

Thus, this “faux app” process allowed me to protect my product while developing a key part of it: the Sign Up/Log In flow.

What’s Essential to Know about SVG

SVG is a relatively new technology that allows for improved rendering of image-like content. It’s a preferred method for adding artwork to mobile and web apps because it performs faster than traditional jpg and png images.

SVG are essentially vectors – you can increase and decrease their size without losing quality (using code)

SVG are better than icon fonts because: they are image tags, which makes them better for accessibility and they have more controls (e.g., class name).

Apps are built using templates. Here’s how to templatize SVG:
use inline HTML, and wrap the SVG in a DEF tag, as DEF prevents it from rendering. You can use it one time and then point to it in the templates. SVG is rendered in the DOM, so there’s no HTTP request (HTTP requests slow apps down) – then use CSS and JavaScript to make it increase or decrease in size, animate, etc.

1) a PNG might render faster if the SVG has a lot of vector points – thus SVG is more for boxier artwork, such as charts and graphs or logos that don’t contain a lot of complex lines

2) SVG needs fallback support for Android 2 (and IE8)

based on LukeW’s notes from C.Coyier’s lecture:

icon set in this artwork can be found here: