Tags: design

1357

sparkline

Thursday, February 15th, 2018

How to Redesign a Tech Logo + Subtraction.com

I think Khoi might be on to something here …but I also think this change in priorities is no bad thing:

Consider the macro trend of these brands all visually converging alongside the industry’s current mania for design systems. That juxtaposition suggests that we’re far more interested in implementing ideas than we are in ideas themselves.

Monday, February 12th, 2018

How I design with CSS grid

Always mark-up first. Regardless of what the kids are doing these days, I stick by my guns and start with mark-up first. A fun experiment (maybe not for you, but definitely for me) is to see how your site reads on Lynx. It does serve as a good gauge of whether the content on the site is structured properly or not.

047: The Web is Neither Good or Bad…nor is it Neutral. It’s an Amplifier with Jeremy Keith – User Defenders podcast : Inspiring Interviews with UX Superheroes.

This podcast interview I did went on for quite and while and meanders all over the place, but it sure was a lot of fun. I’ve huffduffed it, and so can you. Hope you like it.

Saturday, February 10th, 2018

Make me think! – Prototypr

Maybe being able to speak a foreign language is more fun than using a translation software.

Whenever we are about to substitute a laborious activity such as learning a language, cooking a meal, or tending to plants with a — deceptively — simple solution, we might always ask ourselves: Should the technology grow — or the person using it?

See, this is what I’m talking about—seamlessness is not, in my opinion, a desirable goal for its own sake. Every augmentation is also an amputation.

Some questions for us to ask ourselves as we design and build:

  • Empowerment: Who’s having the fun?
  • Resilience: Does it make us more vulnerable?
  • Empathy: What is the impact of simplification on others?

Friday, February 9th, 2018

Everything Easy is Hard Again – Frank Chimero

I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.

I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.

In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.

I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:

Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.

Wednesday, February 7th, 2018

Subverted Design

It’s ironic, isn’t it? Design is more important and respected than ever, which means we have more agency to affect change. But at the same time, our priorities have been subverted, pushed towards corporate benefit over human benefit. It’s hard to reconcile those things.

Friday, February 2nd, 2018

Sketching in the Browser – SEEK blog – Medium

A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp](https://github.com/brainly/html-sketchapp), a more agnostic spiritual successor to AirBnB’s React Sketchapp.

The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.

After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with data-sketch- attributes.

Thursday, February 1st, 2018

Hostage Situation / Paul Robert Lloyd

Paul is wondering why good people work for bad companies.

Maybe these designers believe that the respect and admiration they’ve garnered will provide leverage, and allow them to change how a company operates; better to be inside the tent pissing out, than outside pissing in, right? Well, short of burning down the entire piss-drenched campsite. To think you can change an organisation like Facebook – whose leadership has displayed scant regard for the human race beyond its eyeballs – you’re either incredibly naive, or lying to yourself.

Friday, January 26th, 2018

How to use variable fonts in the real world | Clagnut

The gorgeous website for this year’s Ampersand conference might well be one of the first commercial uses of variable fonts in the wild. Here, Richard documents all the clever things Mark did to ensure good fallbacks for browsers that don’t yet support variable fonts.

Thursday, January 25th, 2018

Design ops for design systems

Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.

Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.

Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.

There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.

Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:

None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.

There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:

Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.

I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:

Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.

Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.

The King vs. Pawn Game of UI Design · An A List Apart Article

I love this analogy and I love this approach—starting with the simplest possible thing and building up from there. This article talks about taking that approach for UI design, but it’s pretty much the same thing I talk about for development in Resilient Web Design.

As Shakespeare once didn’t say, progressive enhancement by any other name would smell as sweet.

Tuesday, January 23rd, 2018

Ampersand Web Typography Conference | 29 June 2018 | Brighton, UK

Save the date! The best web typography conference in the world is back in Brighton on June 29th, and this time it’s at the best venue: The Duke Of York’s.

In fact, you can do more than saving the date: you can snap up a super early bird ticket for whopping £85 saving.

Saturday, January 20th, 2018

Needs must

I got a follow-up comment to my follow-up post about the follow-up comment I got on my original post about Google Analytics. Keep up.

I made the point that, from a front-end performance perspective, server logs have no impact whereas a JavaScript-based analytics solution must have some impact on the end user. Paul Anthony says:

Google won the analytics war because dropping one line of JS in the footer and handing a tried and tested interface to customers is an obvious no brainer in comparison to setting up an open source option that needs a cron job to parse the files, a database to store the results and doesn’t provide mobile interface.

Good point. Dropping one snippet of JavaScript into your front-end codebase is certainly an easier solution …easier for you, that is. The cost is passed on to your users. This is a classic example of where user needs and developer needs are in opposition. I’ve said it before and I’ll say it again:

Given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time.

It’s true that this often means doing more work. That’s why it’s called work. This is literally what our jobs are supposed to entail: we put in the work to make life easier for users. We’re supposed to be saving them time, not passing it along.

The example of Google Analytics is pretty extreme, I’ll grant you. The cost to the user of adding that snippet of JavaScript—if you’ve configured things reasonably well—is pretty small (again, just from a performance perspective; there’s still the cost of allowing Google to track them across domains), and the cost to you of setting up a comparable analytics system based on server logs can indeed be disproportionately high. But this tension between user needs and developer needs is something I see play out again and again.

I’ve often thought the HTML design principle called the priority of constituencies could be adopted by web developers:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors.

In Resilient Web Design, I documented the three-step approach I take when I’m building anything on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

Now I’m wondering if I should’ve clarified that second step further. When I talk about choosing “the simplest possible technology”, what I mean is “the simplest possible technology for the user”, not “the simplest possible technology for the developer.”

For example, suppose I were going to build a news website. The core functionality is fairly easy to identify: providing the news. Next comes the step where I choose the simplest possible technology. Now, if I were a developer who had plenty of experience building JavaScript-driven single page apps, I might conclude that the simplest route for me would be to render the news via JavaScript. But that would be a fragile starting point if I’m trying to reach as many people as possible (I might well end up building a swishy JavaScript-driven single page app in step three, but step two should almost certainly be good ol’ HTML).

Time and time again, I see decisions that favour developer convenience over user needs. Don’t get me wrong—as a developer, I absolutely want developer convenience …but not at the expense of user needs.

I know that “empathy” is an over-used word in the world of user experience and design, but with good reason. I think we should try to remind ourselves of why we make our architectural decisions by invoking who those decisions benefit. For example, “This tech stack is best option for our team”, or “This solution is the best for the widest range of users.” Then, given the choice, favour user needs in the decision-making process.

There will always be situations where, given time and budget constraints, we end up choosing solutions that are easier for us, but not the best for our users. And that’s okay, as long as we acknowledge that compromise and strive to do better next time.

But when the best solutions for us as developers become enshrined as the best possible solutions, then we are failing the people we serve.

That doesn’t mean we must become hairshirt-wearing martyrs; developer convenience is important …but not as important as user needs. Start with user needs.

People and tooling | susan jean robertson

I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.

Tuesday, January 16th, 2018

Laws of UX

  1. Fitts’s Law
  2. Hick’s Law
  3. Jakob’s Law
  4. Law of Prägnanz
  5. Law of Proximity
  6. Miller’s Law
  7. Parkinson’s Law
  8. Serial Position Effect
  9. Tesler’s Law
  10. Van Restorff Effect

Not listed:

  1. Murphy’s Law
  2. Sturgeon’s Law

Monday, January 15th, 2018

Friday, January 12th, 2018

Saving Your Web Workflows with Prototyping · Matthias Ott – User Experience Designer

A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.

A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.

Thursday, January 11th, 2018

TNZ Pattern Library Docs

New Zealand has a pattern library (in Fractal, no less).

Wednesday, January 10th, 2018

Tiny Wins

Making low effort/high impact changes to interfaces.

This reminds me of something we talk about at Clearleft a lot called “tiny lessons”—it’s the idea that insights and learnings don’t always have to be big and groundbreaking; there’s a disproportionate value in sharing the small little things you learn along the way.

Little UI details from @steveschoger, in HTML and CSS

Suggestions for small interface tweaks.