I recently started working on an app that will run on Android, iOS, and in a browser. As is often the case, there seems to be a difference between how people define terms like mockup, wireframe, clickdummy and prototype. Here’s a few thoughts and recommendations from my perspective. 

The app I am developing will be quite complex and extensive. Several “modules” encompassing between 4 and 12 screens, with many points of available information in every screen.

Being experienced, I tend to get anywhere between 80 and 95% of the way based on best practice and assumption. It would be a shame (and inefficient) too rely on this alone. After all, assumption is the mother of all fuck-ups, right?

Assumption is the mother of all fuck-ups.

The complexity requires me to wireframe and user-test every module individually before interconnecting everything and re-testing the whole thing. The fastest approach would be to sketch everything out on paper, then move on to a crude/primitive UI in Sketch or Adobe XD for testing interaction. This is a tried and tested method for designing any web page, UI or app.

So I’m doing just that, but going a little further, leaping where I can. Every time I start a new module or unique screen, I’ll hit the whiteboard and draw. Already at this stage I’ll use diffrent marker colours to depict navigation, UI toggles/switches, inputs etc. Then I’ll jump into Adobe XD (my preferred tool) and get wire-framing.

A colleague saw my in-progress wireframe felt the need to remind me not to get too hung up on design too early. And I agree. But not entirely.

I’ll hit the whiteboard and draw. Already at this stage I’ll use diffrent marker colours to depict navigation, UI toggles/switches, inputs etc.

 

Wireframe Fidelity

The use of best practice and assumption in UI design is a mix of intuition based on experience, using socially/commonly accepted UI elements within the context, and finding the natural order of things (the flow). It’s also about nudging the user using visual weight, contrast, color, and iconography. In my opinion this defies the typical wireframe fidelity, where everything is mostly black and white, pencil lines on paper.

A wireframe might fail in a user test simply because it fails to nudge the user. The user might not spot the information, find the button, get the right overview etc. Because what they are looking for drowns in a monotonous bleached jigsaw of text and lines. Users aren’t architects, they don’t see a house when you show them a blueprint.

Users aren’t architects, they don’t see a house when you show them a blueprint.

Adobe XD to the rescue

I’ve been a fan of Adobe’s introduction of layer comps in linked smart objects for a while. Being able to save different object states like mouse out, hover, ghosted, active, etc. while modifying one file to influence several others simultaneously.

Unfortunately it hasn’t made its way to Adobe XD quite yet.(Photoshop has become a bloated beast that is ill-suited for responsive vector-based design, but that’s a whole other story for another blog post). But there is something similar to be said of using what XD calls “symbols” and the way these can be grouped.

I can build my UI wireframe using XD symbols, and progressively increase the fidelity of the wireframe when I need to. This means I can use rough draft icons, greyscale colours, outlined boxes etc. to begin with, and progressively improve the UI across the entire app design as I go along.

In order to nudge the user, you might need to use a color here or there instead of different icons/buttons with the same shade of grey. In order to improve understanding, you might need to create a custom icon and use it in the wireframe. In order to help the user focus on the most important decision, you might need to start separating elements with color, size, borders, separators and drop-shadows.

Final thoughts

A cold wireframe that works despite the lack of fidelity is a tell-tale sign that you’re doing something right. It can help as a visual checklist to ensure that all the required information and functionality is on the page/screen, but you can’t get reliable test results. 

 

 

Valby Langgade 99, 2. 214 | 2500 Valby | Danmark

Tlf. +45 2557 1288 | digitaldesigner@martinsundstrom.dk