When I was just starting out in design, the phrase “needs improvement” always had a weight attached to it. Upon hearing it applied to my work, I felt judged, unworthy, and less-than. It wasn’t until I started using this phrase as a speaker that I started to understand the sentiment behind “needs improvement”. It can be a positive, encouraging perspective on a piece of work.

I used to wonder why people couldn’t just express negativity. Sometimes ideas just aren’t good, and I didn’t understand why that wasn’t said plainly. It felt like a game of professionalism to find the nicest way to say something negative, and I found the game exhausting. Saying “needs improvement” felt like a hollow euphemism. Wouldn’t it be better to just let go of ideas not worth keeping? And if ideas “needed improvement”, then didn’t make them not worth keeping? …

A blank artboard is intimidating to a new designer, yet this is how I would start projects when I was just getting started in UX. I would take a list of vague requirements from the product team and review the dearth of user research available from the still-growing user research endeavors, then apply those insights to those requirements on a blank artboard.

It was frustrating and inefficient; I frequently found myself battling designer’s block. …

Have you ever been especially fond of a design element that wasn’t entirely driven by user needs? If so, then you’ve probably had a “darling”. I still find them in my work, but thanks to generations of writers, I know how to handle them.

Writers “kill their darlings”. Designers stand to improve our work by doing the same. The idea of “killing your darlings”, usually attributed to William Faulkner or Stephen King, means to remove the things you’re most fond of from your work. For designers, this is anything that you find exciting that may not benefit the user. …

A good narrative elevates a prototype from merely demonstrating task flows to an artifact that unites the team, describes the actions afforded, and promotes user empathy.

The narrative unites the team because every team member can relate to it. Humans are hard-wired to understand information in the form of narrative, so we understand and relate to information woven into a narrative better than we relate to information without narrative context. Since every team member has this intuitive human ability, every team member also derives an understanding of what needs to be done and what purpose that action serves from the narrative. …

Why it’s easier to understand this skill in terms of practical application.

Almost every UX Designer job listing includes some form of “articulate design rationale” as a required skill, and that requirement is there for good reason. It’s also a really vague description that offers a readily accessible, but perhaps naive, interpretation of what it means to do this. I’ve developed a more useful understanding of this phrase after practicing the skill for a few years, and I want to ground the phrase in practical application.

My naive understanding of “articulate” was “to tell or explain”, but I now know that it’s more nuanced than that. Articulation is more like a segment in an ongoing conversation than it is like a lone person’s monologue. If you’ve ever read a line and gone, “that’s what I was thinking but couldn’t express!”, you’ve seen something articulated well. …

Imagine you’ve been tasked with mapping the best kayaking route through an unexplored river. Paddle in hand, life jacket at the ready, and supplies for the trip are secured in your vessel. Your paddle even has a magic ability: when directed to, it will teleport you back to an established checkpoint, to save you the trouble of kayaking back upstream. You climb into position and set out to begin the journey.

Beginning a design exploration within UX feels a little bit like this. It’s exciting and a little bit intimidating. The ultimate goal of the UX process is a clear map of the product to be built, including the information architecture organization and the necessary interactions. The exploration necessarily involves pursuing many different ideas that guide the product in slightly different directions, much like this kayaking trip requires paddling through different branches of the same river. This is the “discover” part of the UK Design Council’s double diamond process. This discovery is also why the paddle can teleport you back to a checkpoint — you don’t have to dismantle your ideation mockups once they’ve been created! Each iteration, or exploration, then, isn’t strictly a linear progression from one idea to the next; the process is a non-linear investigation into the possibility space of design solutions. …

Recently, my organization put out a call for examples of journey maps and user flows. I had just reached the completion point of a flow I was really proud of, and I sent it in with a brief explanation. This flow covered several decision points for key personas and outlined the opportunities to create value for our users. To my delight, the example was accepted! Except, not as a user flow. It was accepted as a journey map.

How did I get these confused, and what are the defining differences between journey maps and user flows?

A user flow is like an itinerary. It gives a high-level list of where the user will go and in what order. It includes points of decision, and outlines the route taken from action to action. A journey map, meanwhile, goes into depth on a particular set of actions and adds context and emotion to the user’s path. A journey map is more like a chronological photo album of travel adventures.

A user flow is a set of actions and decisions the user makes while interacting with a system. It gives a high-level, comprehensive overview of the path the user takes: it’s the itinerary through your system! The flow is primarily about one user and it usually covers multiple parts of a system, reflecting the path a user would take through this system. Incorporating decision points in a flow necessitates including all relevant result states, so the breadth of a user flow diagram may be broad. The user flow generally maps readily to the screens that need to be mocked up or prototyped, since it reflects what the user will see or do in each interaction with the system being designed. It predicates wireframing in particular very nicely, and tends to be forward-looking. Ideal paths might be depicted in a user flow, even if they don’t exist in the live product yet. …

Grammar is the system that underlies the cognitive information of a language and allows a speaker to be fluent. If that language is visual design, then established UX patterns are our grammar, and they’re what make our users fluent in the interfaces we design. I struggled with implementing design patterns until I started thinking about it this way, and now the idea of using established patterns genuinely resonates with me. I now have a “why” for the “just what you do”, and identifying and using design patterns feels like second nature.

So, what is grammar? It’s a lot more than grade school sentence diagramming exercises. Grammar is a set of customs and expectations codified into a language that allow us to derive meaning from it. To say that grammar “underlies cognitive information” basically means that this set of customs has a meaning unto itself. …