Use These 2 Minimalist Concepts to Hack Your Design Learning


I’m the best at psyching myself out when starting new projects.

Before I even sketch out a simple plan of the project, my mind enters ultra-irrational mode:

Well first, don’t I need to finish that Photoshop tutorial to learn how to make a better UI? Shouldn’t I also get a better grasp on typography, color and layout before I start designing this app?

I’ve literally put roadblocks in front of myself.

If you find yourself doing this too, I think you’ll find this post very helpful, and a bit different from other design articles floating around on the interwebs.

_ _ _

The last several months I’ve been getting more in tune with The Minimalist philosophy. It all started when my friend invited me to The Last Bookstore, where Joshua Millburn & Ryan Nicodemus were promoting their new book on minimalism. In their Q&A with the audience, two concepts stuck out to me:

Just In Case: 

“‘Just in Case’ are the 3 most dangerous words to living a minimalist life.” Just in case means acquiring things “just in case” you need them. A pantry full of restaurant condiments. Pairs and pairs of old socks and t-shirts you’ll never wear. So how does this relate to design?

You see, I still experience “just in case” syndrome when it comes to new projects. I start downloading tons of design templates, save links to tutorials, and generally waste time surfing the web.

In my head, I came up with all these nonsensical excuses to “feel ready” for a project, thinking I need to do XYZ before getting started.

So I hoard information and resources, and overload myself with unnecessary things that don’t help me with my project. This is the equivalent of packing 2 full suitcases for a weekend trip.

In essence, I was doing work around the project, instead of working on the project itself. 

(Sidenote: hoarding information is one of the worst forms of procrastination)

Just in Time:

“Just in time” is the antithesis of “just in case.” Instead of packing a bunch of useless items on your travels, bring the most important essentials and just buy whatever you need.

Instead of thinking you have to learn XYZ skill before starting a personal project, just learn whatever skills are necessary along the way.

Example: let’s say you want to work on a dating app as a personal project. Here’s some steps that fall in line with the just in time philosophy:

  1. Brainstorm and dump all your ideas into a Word document
  2. Research and/or survey a few people regarding your project. “Can you tell me about which dating apps you use and why?”
  3. Sketch out some initial ideas and key screens.
  4. Prototype a few screens in wireframing/UI tool. Google things you don’t know along the way, e.g. “How to draw wireframes in Illustrator.”
  5. Repeat

When I was gunning for a position at one of the Big 4 Accounting firms, recruiters stressed that school or “book” knowledge is important, but most people learn 80% of what they need on the job. Accounting or not (yeah, I dodged that bullet), picking up new knowledge while doing the job is the best way to learn. More on that in a few paragraphs.

Striking a Balance

There’s definitely a balance to all this. I’m not advocating that you not learn. It’s not a crime to learn Photoshop before you start your project.

For those completely new to standard tools like Axure or Photoshop, it may be worth investing in a beginner’s course just to get familiar with a program and do basic things.

However, there is a point of diminishing returns when you fall down the rabbit hole of trying to learn every new program / skill on the block (a futile feat). That’s why learning becomes much more manageable when I started to think of projects as learning frameworks.

Projects make good anchors for learning skills (like Photoshop) much faster and better. They provide direction to learn something, rather than wandering aimlessly through an endless tutorial hell.

Over time, here’s what I hope my time and effort expenditures look like:


Why is this important? 

Personally, my biggest mental block is the idea that I need to feel 100% prepared and ready before starting something. Talking to other budding designers, I spot the same theme that holds them back from making faster progress.

The truth is, we’ll never be fully ready and preparing forever is a big lie. So learn it as you go, and enjoy the ride.

7 Reasons Why You Should Date a UX Designer

We're halfway to Valentine's, yo

We’re halfway to Valentine’s, yo

IF you were to date someone purely based on their profession, then consider putting User Experience Designers at the top of your list.

Since User Experience Design as a field is still relatively new, it could use some introduction to stand out from long-established roles such as the engineer,  financial analyst, doctor, or lawyer.

It’s already halfway to Valentine’s Day,  and not too early to think about what you’re looking for in a partner. Let’s dive into the 7 traits that make User Experience Designers a desirable choice when it comes to dating.

#1: We don’t assume.

Or, at least, we try not to. This is one of the mantras that UX Designers live by:

You are not your user.

Don’t you hate it when someone assumes something about you when they know absolutely nothing about you?  Or worse – when someone likes or dislikes something and assumes you have the same preferences? Fear not – UX Designers are trained to avoid assumption.

Just because a UX Designer likes to mountain bike and garden on the weekends, doesn’t mean he/she expects that is what his date enjoys doing.

It’s part of the UX profession to 1) be observant and 2) do research. All in order to understand someone else’s preferences, behaviors and idiosyncrasies. UX Designers ask questions and try to never, ever make big assumptions.

#2: We test things out

Falling in line with the “never assume” philosophy, UX Designers have a mind to try new things. It keeps the relationship fresh and exciting. Variety is the spice of life, as the saying goes…

On the flip-side, when the going gets tough, User Experience Designer’s don’t just let problems sit idle. They test things out and try to find a solution.

Nothing is more ugly than the words, “Well, that’s just the way it is.” If it’s something worth solving, having a UX Designer as your partner can turn an unpleasant situation into a learning experience.

#3: Jack of all trades, master of some.

The list of responsibilities a UX Designer has is extensive, typically starting from research to final design (with or without other artists and programmers). If you want to date someone with skills, UX Designers won’t leave you in want of more.

More and more, UX Designers are expected to have a “T-shaped” skill set. This means having a broad skill set (comfortable with the entire UX design process) but also having expertise in one or more areas. Depending on the needs of a company, it’s not unusual to see UX Designers have expertise in:

  • Visual Design
  • Product Management
  • Front-end programming
  • Researching & Testing

Indeed, UX Designers wear many hats and have a flexible, wide skill set.

#4: Understanding that Things are Interrelated 

Because UX is an intersection of many fields, you’ll see that UXers can hail from a wildly different backgrounds such as library science, business, graphic design and more.

This diversity brings an understanding that seemingly disparate things in life are actually interrelated. How does this relate to dating?

Well, UXers don’t like to put people in buckets and recognize that everyone brings value.


UX is interdisciplinary. Buckets are for water, not for people.

We’re also the last person to discourage you from switching careers; rarely has anyone been a UX Designer their entire life. Transitioning in and out of different fields and roles is a common thread across this industry.

#5: Empathy 

Dating someone who sympathizes with you is OK. They feel bad that you had a bad day at work. They feel sorry for you that you’re frustrated with your mom. But UX Designers understand that they’d lose their jobs if all they did was lament with customers on how unusable their product is.

Empathy is better.

Being able to “take a walk in someone’s else’s shoes” is essential to the job of a UX professional.

Great designers care. They constantly think about the users and their problems as well as the needs of their teammates. It will sound weird, but… being human is part of the job.

One of the best ways to reach true understanding is to prioritize what users do, instead of what they say.  Actions and behaviors are worth more than words.

Now wouldn’t you like a partner who takes out the trash, instead of saying they’ll take out the trash?

#6: Team-oriented 

No one likes being in a one-sided relationship. Whether she only wants to “date” you online, or he insists on keeping the relationship a secret, it’s not a good time for anyone. On the other (much nicer) side of the spectrum are team-based relationships.

Professionally, UX Designers are expected to collaborate and work well in teams in order to succeed.

Yes, many UXers are “UX Teams of One.” There’s even a whole book written about it. But the title belies the fact that regardless of being the only UX Designer in a job or not, working with others is essential to success.

We work with executives and business to craft strategy. We work with programmers to realize designs in code. Above all, we work with customers to understand their needs and pain points.

If you’re looking for a partnership instead of just a temporary fling, UX Designers may very well have that team-based mentality you’re looking for.

#7: Humility

It’s ironic to end this list of great traits about UX Designers with this trait, but it’s true. Humility is absolutely crucial to this profession.

In many instances, UX Designers have no choice but to develop humility. Having to pitch, explain and defend your designs over and over again means that UX Designers learn to divorce their ego from their design.

Sure, we might have spent 30 hours this week working on a new design. But if business requirements change or compelling user research emerges, then we need to prepare to scrap our designs. And do it all over again.

This means learning to compromise, say sorry and having a small ego. All traits that a good UX Designer is likely to have.

Being a UX Designer requires a healthy amount of self-doubt. It’s essential for having an open perspective and allowing new ideas to flow in.

We sometimes hear people say “that person suffers from a lot of self-doubt”…Clearly, self-doubt is meant to describe someone that is weak or has low self-esteem. However, for a designer, a little self-doubt can actually help them be more open to the possibly that their design can always be improved. A truly good designer will never feel they have achieved the perfect design

_ _ _

AND THERE we have it, 7 good reasons to date a User Experience Designer. This article may have very well be named 7 Soft Skills that make a good User Experience Designer. But you gotta have a little fun sometimes.

Are you a User Experience Designer or dating one yourself? Tell me in the comments below if this syncs up.

How to Remember the 3 Vital UX Laws (and impress your interviewers)

Warning: reading this article will make UX Beginners more informed, sound smarter, and potentially wow a UX hiring manager.

Warning: reading this article will make UX Beginners more informed, sound smarter, and potentially wow a UX hiring manager.


In a competitive UX job market, those who pay attention to the details and ask the high-level questions stand out. Questions like:

Do our designs solve problems in the best possible way? 

Here’s a quick and effective framework to answer that very question:

Know Your Usability Laws + Test Your Designs 

It sounds simple, but you’d be surprised how often the classic UX laws are ignored in digital design and beyond. In fact, you may be educating many a hiring manager about the UX laws you’ll be learning today.

The majority of this post will cover the top 3 UX laws that UX Beginners can benefit from – and funny ways to remember these laws easily.

Then we wrap up with how these laws, combined with testing, leads to more powerful designs.



Disclaimer: there is a ton of research that comes with each law, but for the purpose of the article I try to make each one of these laws actionable and easy to remember for the beginning UX designer.

I certainly don’t cover all the bases here; there are many variations & challenges to the law. Google will pick you up should I fail to give good explanations :)

Hick-Hyman Law (aka “Hick’s Law”)


Increasing the number of choices will increase decision time. [Wikipedia link] [ link]

Sounds like common sense: more choices leads to more time evaluating which choice to make. The terms “analysis paralysis” or “death by numbers” may come to mind – having too many things to choose from can overwhelm users, sometimes making them quit the task at hand completely.

Good Application of Hick’s Law:

In ‘N Out Menu: This simple menu has worked for over half a century. Even indecisive eaters will find it a challenge to take more than 1 minute to decide what to eat.

For a chain the size of Best Buy, its website has a surprisingly simple and streamlined menu.


Bad application of Hick’s Law:

What’s going on? Customers (especially new ones) are inundated with options.

Unlike Best Buy’s Menu, Staples’ “mega menu” can be quite overwhelming.


How to Remember Hick’s Law: 

Google defines hick as a person “who is regarded as being unintelligent.” 

Keep it simple for the hicks, don’t overwhelm them with too many choices. Deciding is hard.

Fitts’s Law


The time required to rapidly move to a target area is a function of the distance to the target and the size of the target.
[Wikipedia Link

In English: The closer and bigger something is to you, the easier & faster it is for you to touch it (accurately).

Ever used an app with tiny, easy-to-miss buttons? It baffles me that people with big fingers manage to send intelligible texts.

Good Application of Fitts’ Law:

Check out the Yelp app homepage. Each of the main categories – particularly search, are big buttons that make it fast & easy to search for reviews on the go.


Bad Application of Fitts’ Law: 

This is not necessarily a bad design – it’s just showcasing how Fitts’ law is not maximized here; smaller target areas = harder to touch accurately.


How to Remember Fitts’ Law:

“How easily can I Fitt my finger on this button?”

Miller’s Law


The observation…that the number of objects an average person can hold in working memory is about seven
[Wikipedia Link] [ link]

This is probably the most contentious UX Law. It should really be a UX suggestion. Miller’s law is often used to justify that you shouldn’t make users remember beyond the range of 7 +/- 2 items (5 on the low end, 9 on the high end).

Regardless of the exact # that users can hold in their working memory, Miller’s Law tells us that users remember information in chunks. Providing the most relevant information in logical groups is called chunking, and this helps users absorb information and finish their tasks.

How is Miller’s Law different from Hick’s Law? Their subtle differences often work in conjunction. Hick’s law specifically addresses the time & effort required to make choices, whereas Miller’s law focuses on memorability and focus. Both will affect the speed, effort and time it takes for users to use an application.

Good application of Miller’s (+ Hick’s) Law

New product landing pages like Coin really nail it. There are only 2 – 3 actions: Watch the video, scroll down (and see the cool parallax effects), and Pre-Order.



The only choice to make, per Hick’s Law, is whether to Pre-order or not. The rest of the links such as Blog, About Us, Jobs are de-emphasized so that only those who are really looking for other information will care to find them.

Once you select Pre-Order, the form only provides the most essential form fields for checkout. This is Miller’s Law at practice: the minimal amount of form fields for someone to provide payment. The form is also chunked into the groupings Quantity, Payment and Contact.

And what do you know, there’s a total of 7 form fields. 


Bad Application of Miller’s Law

Check out There are 9 top-level categories, but they seem disparate and thrown together randomly. We have seeming similar categories such as News, Community, and Magazine – which may potentially be chunked together.


Now compare that to Not perfect, but the 8 available categories they present already seem more logical and a cohesive whole than


How to Remember Miller’s Law:
It’s hard to remember many things at once, especially if you’re drunk off Miller’s beer. (Inspired by Cesar Gomez’s use of “It’s Miller Time” from the Miller Lite commercials).

Bring it all together:

This blog post will be a fail if I ignored any of the principles myself. Instead of inundating you with dozens of smaller laws, these are the top 3 for UX Beginners to be knowledgeable about. To make these laws even easier to remember, here’s a ridiculous story that may help:

A country Hick has too many guns to choose from (death by choice). None of them Fitts his hands correctly; when he shoots, he often misses – especially small targets far away (target acquisition). Instead, he remembers that he’s better at drinking Miller beers (memorability). With some focus he can down 7 +/-2 bottles. No wonder he’s so chunky.

Nonsensical? Yes. But hopefully easier to remember.


Ironically, a “law” is something that’s not supposed to change, like the law of gravity. But when applied to user experience design, the laws are secondary to the goals a particular product needs to achieve for both the business and its users. Under this context, the best solution is to apply user testing to see what works for the product and its audience.

1. Existing product

Design teams can analyze existing products through the lens of these three usability laws.

First, it always helps to have some baseline metrics to measure against. You get this by asking the questions: what are the intended user flows, and based on current designs, how are those user flows performing? Do you have a page element that you really want users to click on, but it’s driving low conversions compared to other parts of the page?

Based on what you find, you may apply one of the usability laws to increase conversions on a desired user path. For example, maybe only 3 out of 5 links on a page really matter. Perhaps remove 2 of the links and emphasize the more important link. This is a pedestrian example, but you get the point.

Make changes, then test the new design with real users. Even getting the opportunity to sit with 3 – 5 people and observing how they interact with your product is invaluable.

*Tip: The relationship can be a symbiotic one. Don't what you should test? Look to the three UX laws as solid starting points. Don't know if a usability law is working with your design? Test it.

Tip: The relationship between laws and testing is a symbiotic one. Don’t know what you should test? Look to the 3 UX laws as solid starting points. Don’t know if a usability law is working with your design? Test it.

2. Creating new products/features 

Whether it’s a completely new app or section to your website, this is a good chance to create an effective user experience from the beginning.

Designing with Hick’s and Miller’s Laws in mind, for example, help you create a design that allows the user more focus to complete tasks, and less superfluous options that lead to decision paralysis. Do you really need make your users input their age and location, or is just taking their emails enough? (Or perhaps you can collect some of this data automatically without form input).

Then, just as with existing products, you’d test your design with real users to identify qualitative findings (user confusion) or quantitative metrics such as the time it takes for a user to get to a certain part of your product.

Is your user spending more than a minute trying to read and understand your home page text? Maybe your findings lead you to find that the home page has too much copy, or that the copy itself is confusing. Tweak that.

Good UX design should be iterative, and ideally user testing is tied into the process to continually uncover insights.


  • Balanced view of Miller’s Law [UX Myths Article]
  • Fitts’ Law [Princeton Article]
  • Balanced view of Fitts’ Law [Smashing Mag Article]
  • Hicks Law [UX Myths Article]

Going in for an interview or networking event? If there’s an opportunity to talk about design and prove your UX background, sharing your knowledge of these UX laws (which, really, can be applied to many other facets of life) can help you establish credibility in the field.

If you’re interested in more “Impress Your Interview” posts, leave a comment below or sign up for UX Beginner’s newsletter below to email me – I want to know if these kind of posts add value to my readers.

The Last Post You’ll Read On Whether UX Designers Need to Learn Code


This is the #1 question I get asked by UXBs: Do UX Designers need to know how to code? It’s one the most contentious topics in the design community today.

With the tech world moving at such a fast pace, hiring getting more competitive, and the proliferation (and consolidation) of roles…this all adds up to a lot of confusion in the marketplace. This article will help clarify any confusion, help you stay away from fruitless “should you code” debates in the community, and provide an easy action plan.

A 1-Minute Explanation of Why UX Exists

To resolve this should-I-be-coding-because-everyone-is-doing-it syndrome, let’s remember the original purpose for the birth of UX design as a profession. How software products used to be made:


Someone has an idea and they go straight to programming the damn thing. But if 1 business requirement changes – major portions of that program, if not all of it, needs to be rewritten. It’s costly and extremely stressful.

Out of a combination of forces including the rise of design, startup thinking, usability testing and more, the field of user experience began to take shape to address how research, testing and design thinking can be employed to make product that are better + faster + cheaper.

So don’t forget – the mark of a UX designer is to research, validate, design and test ideas as efficiently as possible. There’s a reason why in the past several years a slew of prototyping tools have come to market.

Now, how does that relate to whether I should learn code or not?

Reminding ourselves the value of UX design helps us reframe the “should I learn code” question into a more effective one:

How much code should I learn, and for what purpose?”

As I wrote in the Agencies vs Startups vs Big Corporations article, different organizations have different needs. If it’s your goal to work at a startup, then learning code may be much more applicable than compared to working at big corporation. Or maybe you have a side project and don’t want to spend 10 grand on programming something that might not even come to fruition. So know your goals first.

Take a look at the “coding spectrum” below. This article is targeted at those in group A – those who tend to feel most anxious about not knowing code.


what to do?

The good news is that the majority of UXBs can benefit from moving up the spectrum from  a -> b; from knowing no code to getting a basic-level understanding of it.  And it’s pretty painless to jump to c  (dabbling in some code) –  as you’ll soon see.

getting that basic understanding now, in 2 minutes
(getting from a -> b on the spectrum)

Instead of fruitlessly wondering if you need to learn code & invest lots of energy +  time into it, do this: understand code at a basic level. This is beneficial for many reasons:

  • helps you better communicate with developers
  • cuts down on design and rework time
  • Example: Designer: “I spent 5 hours on these 6 diff designs.” Developer: “We can’t do that on iOS.”

Being a UX Designer means you need to demonstrate your thinking visually, and front-end code can be part of that process. That’s also why you don’t need to learn back-end code (unless you want to of course).

Here’s a quick primer on the difference between the two.

Front-end code is just what it sounds like: code that affects what you see on the “front-end.” What you’re looking at right now is HTML and CSS.

HTML = the actual content of a website. The text you’re reading right now. It’s the basic skeleton and building block of any webpage. Using HTML you’d define things like the header, footer, body paragraphs and more.

CSS = the style. You take the skeleton of HTML and dress it up with CSS. You take that header and say “yo header, I want to make you red, with a thick border, and super wide.” That’s what CSS does.

HTML & CSS go hand-in-hand. But to fully harness the magic of interactions and add behavior to an otherwise static page, JavaScript comes in.  This article does a good job of explaining JavaScript and its relationship with the other 2 languages.

So there, you already know at a basic level what front-end development is.

It’s creating the content with HTML, styling it with CSS, and adding behaviors + interactions with JavaScript. That means that the back-end deals with things you don’t see that power an application.

An analogy: front-end is the exterior body of a car, while back-end is the engine that actually drives the car.

Side note: Even most unicorn-seeking recruiters shouldn’t expect you to do back-end programming and handle what happens in a database.

Even knowing this much and being aware of front-end vs back-end will help you understand how your designs translates to programming.

Have a really unique layout and tons of graphical effects like drop shadows and gradients? That’ll require more styling & layout, so more CSS. Got a ton of cool transitions and different interaction states based on what the user is doing? More JavaScript. I’m by no means well-versed in front-end code, so here are some quick reads to get a better understanding:

dabble in code to better solidify that basic understanding
(going from b -> c on the coding spectrum)

I encourage everyone to practice just coding up a little HTML & CSS in order to satisfy your curiosity & strengthen that basic understanding of what code can do.  The good thing is that you can do it all in one focused weekend. Go through Codecademy’s HTML & CSS sections. That’s it. There’s literally thousands of tutorial sites and resources, but I find it most helpful to recommend one robust site that does it well. You’d be hard-pressed to find basic tutorials more engaging than Codecademy’s.

the conclusion, and what you’ve learned

This article was designed to help UX Beginners get up to speed as fast as possible, and take action. There will be endless arguments on whether UX Designers should code or not. Stay above that noise, because it’s not going to help you. Instead, we focused on these things:

  • context & history: research, design, and testing are the bread and butter of UX designers to help cut time and costs in the development process. As long as you don’t lose sight of that, you’ll be fine.
  • your goals: where do you want to work? What skills are required in your current job, or the next job you want?
  • demystify code by developing a basic understanding of how code is used. This also relieves unnecessary guilt and anxiety over “not knowing how to code”
  • if feeling inspired, dabble in code to strengthen that understanding and work with developers better. Win win for everyone.

If you do find that you enjoy code, there’s no one stopping from learning it seriously. It just requires a tradeoff in time and energy, and needs to sync up with your personal goals.

If you feel like you are more interested and can get more out of doing something else, focus your efforts there instead. Better to be a great user researcher than an ineffective coder.

At the very least, you’ll relieve yourself of the guilt & anxiety of not knowing code, and have at least taken the very important step to understanding it at a basic level. I’ll end this one big side tip: talk to developers a lot. More so than any book, you’ll pick up on what designs are feasible/not feasible by understanding what developers need to go through to turn your designs into code.