An interesting image to point out above is the last one (bottom-right). You can see that my sketch is close to what I ultimately designed.

Concepting & prototyping.

All of these ideas and designs are informed and evolved by concepting, prototyping and discussing with the team. It’s good to chat through ideas with other designers and developers, and even the target audience when possible. For example: One particular idea came from me discussing an early (product) design with an MFA illustration student at SVA. A fresh perspective always helps, especially for a product of this complexity.

We were working to pretty intense timeframes on this project. There simply wasn’t time to build any complex prototypes. But what I did do was to create a series of PDF walkthroughs using Layer Comps in Photoshop, showing the mouse cursor move around the screen, demonstrating every interaction, feature and user flow within the product. These allowed developers (and other stakeholders) to critique and/or understand all functionality and the user flow — so they knew what was to be built, and also identify any potential flaws in the UI/UX, prior to the build and testing.

Below is (a video of) one example of these PDF walkthroughs:

Prototype/walkthrough showing global customisation in the project editor

Detail in design.

Simply put: Take the guesswork out of it for the developers. Your team needs to understand what needs to be built. It is not their job to fill in the blanks, make it responsive, or guess what happens in any given scenario. I can’t overstate this enough — I’ve experienced so many designers designing and considering 20% of a product, and not thinking things through.

In addition to the walkthroughs, user flows and prototypes I talked of earlier, I also like to create detailed specs for all the UI components, features and brand. I feel these are important when you have a large team, so everyone is on the same page, with one central point(s) of reference. The specs aim to cover all scenarios, from rollover states, to errors, active/inactive states etc…, and also cover px values and dimensions (I even go as far as including basic CSS).

Promote/encourage pixel perfection in the build. Lead by example, and set the bar high.

The more detail you include in your designs, the less questions the developers will have, and the less time you will spend managing the build. So you can focus on designing, testing and improving the product.

Also, the nice thing about taking the time to create these ‘UI kits’, is that it’s easier to update the product (design) in the future. There’s no need to update hundreds of mockups, you just update the specs.

Below are a few examples of these styleguides and specs: