There is no time. There is hardly ever enough time.
Every now and then, I observe cases of UX solutions not being demonstrated in-detail prior to development. That means designers have neither illustrated the experience they designed, nor tested or reviewed them. They have not demonstrated the use-case in-detail — the complete workflow — to review it and see if it works. More often, features are being used for the first time, once development is completed. And usually, this is a little too late.
Sketching is a powerful tool for designers to bring ideas and concepts out to live, tell the story in-detail, and see if they work. From high-level concept to detailed design, from using pencil and paper to using a digital tool — as a sketch evolves, it’s likely that solutions get more mature, details get finer, and interactions get clearer. Designers who walk themselves through a complete use-case, test the experience detail by detail, and get back to the sketching table to fix whatever requires modifications, improve their solutions and ultimately evolve their professional skills.
This is an educational process.
Having said that, I’ve observed designers who practice this powerful tool of sketching in such a fashion that — in my opinion — entirely misses the point. Some designers skip the sketching work to begin with. Some do sketch wireframes; however, they do so while applying a technical approach. Some relate only to the feature they are dealing with, while ignoring other parts of the broader context. As a result, the experience is not being fully illustrated or reviewed during the design phase, but only after development is completed. Only then, usability issues and broken concepts are revealed, so designers must get back to the sketching table and re-consider their solutions. The consequences are significant, because each unit in the product-manufacturing chain must redo their work, which means high costs in terms of time and money. And a lot of frustration to everybody.
My father always says: ‘You better use your head in front, or you’ll burn your shoe soles later’; And I say: ‘Review your design upfront, or tears would be shed later’; test your design — be your design’s first user.
How it [shouldn’t] work
Skipping the sketch work. Entirely.
I’ve encountered cases in which no sketch work is being done prior to the development phase. Alternatively, specification document that includes a features’ static illustration is created; however, the detailed experience is neither illustrated step-by-step nor reviewed prior to writing the contextual specifications.
‘There is not enough time’ is the most common, however, not the only excuse I’ve encountered. Sometimes, it’s because a feature is so tiny — part of, or additional functionality, to a much larger one — so designers, product managers, or other stakeholders think sketching would be a waste of time. Never is it a waste of time. Even when adding a single field to an existing form, illustrating the experience in-detail can reveal some unpleasant surprises this additional functionality might trigger.
That allegedly tiny change may break the flow by causing serious disruption in the way users think, act, or expect things to be like. It might also break dependencies between elements, require additional information pieces, make design patterns seem wrong, and more painful usability issues. Even when dealing with a small feature or additional functionality to an existing one, don’t skip sketching — be your design’s first user.
Sketching the technical way
Here, I’m talking about designers who occupy a technical mindset: they relate to experience design as if it’s all about putting together UI components. Basically, they use wireframe as a tool for delivering technical UI specifications. I observed an extremely ‘technical’ designer, who flattens the experience by spreading all the states of an UI component within a screen, as if it is a natural part of a use-case. At the same time, he totally ignores screen’s boundaries, using its peripheral space as if it were a billboard, featuring technical specifications and comments.
A ‘technical’ sketch neither illustrates a use-case nor an experience. Reviewing this sketch work is more like mission impossible — chances to reveal any potential issues are low. Don’t sketch UI components or guidelines, illustrate user experience; don’t sketch specifications — be your design’s first user.
Sketching only parts of the use-cases
Sketching UX solutions, without putting them in their broader context, is yet another example I’ve encountered of using the practice of sketching the wrong way. Focusing only on one piece of a solution, without considering the broader context — what comes before (use-case initiation, trigger point) and what comes after (use-case closure) — means doing just part of the job. It means telling only part of the user story.
Designing a form without demonstrating the initiation screen that holds the commit element — which triggers this form appearance to begin with — is one common example of not considering the complete end-to-end solution. Similarly, not illustrating the landing view that follows form submission is another example of not considering the whole story.
In my article ‘Reviewing the UX Review Process: God is in the Little Details, and on the Big Chunks’ I specified the ‘Macro’ state of mind, which is a practice of paying attention to use-case’s major chunks (steps, pieces) to validate if the broader context works, if the narrative makes sense.
Another form of off-target partial sketch work is — in my opinion — illustrating only the feature of the matter, while not including other elements that lay under and around it. I’ve observed, for example, a detailed wireframe of a heavyweight screen, which holds a multi-column table, filters, and action items, while the application header and navigation pane remain blank. Sketches missing parts and details seem less crowded, so the illustrated experience is not like what users will eventually experience in the real world.
Cognitive and visual load can be evaluated only once all details are put in place.
If designers don’t put all visible UI elements of a given context, they don’t consider all the parts that eventually create the overall cognitive load. They can’t exercise empathy towards the end users, who will eventually experience these potentially crowded designs. Sketch the end-to-end overall use-case to test your solution — be your design’s first user.
Summary
Depeche Mode’s famous song ‘Walking in My Shoes’ refers to empathy. It says: “Try walking in my shoes | You’ll stumble in my footsteps | Keep the same appointments I kept | If you try walking in my shoes.” UX designers ought to walk in their user’s’ shoes — they better be their design’s first users.
When used properly, sketching is a great tool for exercising empathy, validating, and delivering user experience. Whether dealing with low fidelity wireframes, detailed mockups, or high-fidelity models, walking through an entire use case is crucial to detect potentially missing pieces in the design, unclear or broken workflows, required alternative selections, failure scenarios, feedback mechanisms, and so on. Ultimately, once designers resolve some elementary design issues by reviewing UX solutions first and refining and improving them following that, running usability tests with real life users later may reveal deeper issues or things not taken into account. This process is crucial for designer’s personal and professional development. It enables us to evolve our skills and become much better professionals. For the last time: test your design — be your design’s first user.
