Copy

You’re receiving this letter because you signed up for one of my free courses at UI Breakfast website, bought The UI Audit or another book of mine. If you prefer not to receive such letters, no hard feelings, please unsubscribe below.

--

Introducing The UI Practicum

Hi <<Your First Name>>,

Remember I told you I’m building something great? A paid newsletter similar to the practicum sections found in The UI Audit? Well, here it goes: I’m launching The UI Practicum today. And the best news, I decided to make it free, available exclusively to this list!

Why I’m making it free

My head was spinning round and round while I considered various pricing models. I really wanted to ship some great UI/UX content on regular basis, and to make it more affordable than expensive books and courses. But doing so would mean producing the content for the small list of paid subscribers. It’s hard to guess how much I would sell — 50? 100? 200? But my experience with online sales shows that conversion rates apply in any case. If I didn’t make substantial money then, why would I want my best content locked up behind the paywall?

So I made a tough decision: I’m making this newsletter free for all 6,000 people on my list, and introducing a patronage subscription for those who are willing to pay. I’m setting my expectations low, but if you really want to support this awesome newsletter — please purchase a voluntary subscription using this link.

Who is this for?

The UI Practicum would be useful for anyone dealing with UI/UX on daily basis: SaaS founders, UI/UX designers, developers, and product managers.

What goes into each issue?

Each issue addresses a specific problem that you struggle with. The primary focus here is UI/UX design, but it can’t be treated in isolation — we’ll also get into customer development, product strategy, and some marketing.

First, we’ll go over the problem and underlying reasons. Then we’ll dive into the practicum section: what exacts steps you can undertake today to address this problem within your own business.

So without further delay, onwards to the first issue!

Regards,
Jane.

UI Practicum #1. How to Justify Your Design Decisions

No one works in isolation. Not only you have to take design decisions, you also need to prove their worth to other people. Here are some real-life scenarios when it’s necessary:

  • SaaS founders explaining their product design decisions to co-founders and investors;
  • designers and UI/UX consultants presenting their solutions to clients and top management;
  • a design team approaching the development team to introduce changes in the software.

Let’s face it, quantitative user research doesn’t work in most cases. In smaller companies, there’s usually no budget (time, resources) for this. In larger enterprise software, the gap between the UX department and the final user is so huge that user research becomes impossible logistically. Those who produce, sell and buy enterprise software are rarely the actual users.

Use design principles and logic to prove your decisions

But what do you do then? The answer is, you use the key design principles to find logic in your own solution. That might sound a bit backwards, but it works.

Here are the principles that will help you explain almost any design decision (alone or combined):

Proximity and spatial distribution of elements: in common software, elements usually have traditional locations for things (navigation is on top or left side, user menu is on the top right side, search and filters are above the data table, etc.) This is good enough proof by itself. This helps to calm down crazy ideas of messing with common controls.

Task-focused approach: approach any screen/area from a standpoint of a single most important use case, and justify your decisions based on that.

Visual hierarchy: each screen (or screen area) should have one kind of control that represents one important action, without other controls getting into the way. This helps to calm down requests “to make things bigger.”

Monotonous data: if the work happens around the same type of data, then it should definitely be combined into a single huge list supplied by a comfortable set of filters and drop-down menus (which can most often replace tabs or other complex controls).

Validation by mass platforms: unfortunately, there’s no “common UX patterns” encyclopedia. But if you can, find similar examples in mass-market software. That’s “social proof” for those who you’re presenting to. Plus, most likely, these companies have better budgets to conduct proper user research and validate their UX solutions.

Practicum

So any time you need to take a design decision and prove it to others, follow these steps:

  1. Try and find similar examples in respectable mass-market software that you know. This little research might even shed new light and make you change your initial decision.
  2. Look at the list of principles above, and try to think which of them caused you make this certain design decision.
  3. Remember that you’re the expert and you can invent new principles based on your experience (and this new case).
  4. Write down your thoughts in a small list to clarify them.
  5. Confidently use these principles to logically present your solution to the audience.

Enjoyed this issue of The UI Practicum? Consider becoming a patron. Click here to support this newsletter with a voluntary Gumroad subscription.

You are receiving this email because you signed up at UI Breakfast website, in person, or bought my book. If you prefer not to receive these updates anymore, feel free to unsubscribe below.

unsubscribe from this list    update subscription preferences    view this email in your browser