A road comes to an end with a two-way sign, with the options to turn either right or left
A road comes to an end with a two-way sign, with the options to turn either right or left
Photo by Kyle Glenn on Unsplash

“Why did you make that choice?”

As a new designer, my answer to this was an on-the-spot attempt at justifying something that hadn’t really been a conscious choice at all. I didn’t recognize that there was a choice to be made, and so I hadn’t thought about its motivation until an explanation was requested. I used to stumble my way through a justification that didn’t necessarily make sense because I wanted to have an answer.

After a while, I started to understand that iteration is part of the design process, and that sometimes it’s okay to not know things. I became less embarrassed about not knowing things, and so I started answering this question more honestly: that I didn’t really think through why that choice was made. …


Image for post
Image for post
Photo by Bruno Nascimento on Unsplash

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? …


An hourglass sits among gravel as its sand pours from top to bottom.
An hourglass sits among gravel as its sand pours from top to bottom.
Photo by Aron Visuals on Unsplash

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. …


A man and a woman stand facing each other in front of a sunset.
A man and a woman stand facing each other in front of a sunset.
Photo by Travis Grossen on Unsplash

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. …


Worn paperback books sit slanted along a shelf
Worn paperback books sit slanted along a shelf
Photo by Robyn Budlender on Unsplash

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.

A projector broadcasts an image into the distance.
A projector broadcasts an image into the distance.
Photo by Alex Litvin on Unsplash

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. …


A river flows into the distance, flanked by mossy green cliffsides.
A river flows into the distance, flanked by mossy green cliffsides.
Photo by Martin Sanchez on Unsplash

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.

Image for post
Image for post
Photo by Sarah Kilian on Unsplash

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. …


Paper sketches of lo-fidelity screens
Paper sketches of lo-fidelity screens
Photo by Halacious on Unsplash

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. …


A hand holding a pen hovers above a work station, about to draft ideas
A hand holding a pen hovers above a work station, about to draft ideas
Photo by Kelly Sikkema on Unsplash

A design system is a library of patterns and components used across multiple projects. Craft’s DSM and Figma’s Team Library are platforms that support design systems. The most important aspect of a design system, though, isn’t its platform nor its components: it’s the people who use it. Taking advantage of the social aspects of a design system can amplify its effectiveness, both for you, your colleagues, and your users. The design system itself might be made up of patterns and components, but on a deeper level, it’s a communication tool.

The single most effective means of using a design system is very social and very simple: share your work! Most design systems are as iterative as the projects they serve, and contributing the knowledge of your particular application of a design system’s component part helps keep that iteration on track. When you share that you’re using a design system component, you’re adding to the institutional knowledge associated with it. You’re creating an example case for future designers. You’re helping to define when that pattern is the right choice, or even expanding the use cases for using that pattern. If you work with design system or ecosystem designers, you’re doing them a favor, too. …

About

Rania Glass

UX Designer | Empowering humans through technology

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store