Tags: job

53

sparkline

Wednesday, September 22nd, 2021

Design research on the Clearleft podcast

We’re halfway through the third season of the Clearleft podcast already!

Episode three is all about design research. I like the narrative structure of this. It’s a bit like a whodunnit, but it’s more like a whydunnit. The “why” question is “why aren’t companies hiring more researchers?”

The scene of the crime is this year’s UX Fest, where talks by both Teresa Torres and Gregg Bernstein uncovered the shocking lack of researchers. From there, I take up the investigation with Maite Otondo and Stephanie Troeth.

I won’t spoil it but by the end there’s an answer to the mystery.

I learned a lot along the way too. I realised how many axes of research there are. There’s qualitative research (stories, emotion, and context) and then there’s quantitative research (volume and data). But there’s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!

Steph was a terrific guest. Only a fraction of our conversation made it into the episode, but we chatted for ages.

And Maite kind of blew my mind too, especially when she was talking about the relationship between research and design and she said:

Research is about the present and design is about the future.

🤯

I’m going to use that quote again in a future episode. In fact, this episode on design research leads directly into the next two episodes. You won’t want to miss them. So if you’re not already subscribed to the Clearleft podcast, you should get on that, whether it’s via the RSS feed, Apple, Google, Spotify, Overcast, or wherever you get your podcasts from.

Have a listen to this episode on design research and if you’re a researcher yourself, remember that unlike most companies we value research at Clearleft and that’s why we’re hiring another researcher right now. Come and work with us!

Wednesday, September 15th, 2021

Design engineering on the Clearleft podcast

If you’re subscribed to the Clearleft podcast, then the latest episode is winging its way through the ether to your podcast software. The topic is one close to my heart: design engineering.

I wrote about this role back in February. I think my fervour comes across in that post and you can probably hear it in the podcast episode too.

As ever, I end up asking the question, “So what exactly is insert topic of the podcast episode here?”

I’ve got some smart folks answering that question. There’s an excerpt from Tobias Ahlin’s talk at this year’s UX Fest. And when I interviewed Adekunle Oduye for a previous episode on prototyping, we also discussed design engineering so I pulled out the relevant bits. But the bulk of the episode features the voice of Trys Mudford.

As you can gather from the many posts on Trys’s blog, he has a lot to say on the topic of design engineering. Luckily for me, he says it all with a clear, articulate delivery—the perfect podcast guest!

This episode finishes with a call to action (oh, the synergy!). If, after listening to 23 minutes of discussion on design engineering, you find yourself thinking “Hey, I think I might be a design engineer!”, then you should definitely head along to this job opening at Clearleft:

We’re currently looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production.

Have a listen to episode two of season three of the Clearleft podcast and if you like what you hear, come and join us!

Monday, August 9th, 2021

Design Titles

Keep refreshing until you find your next job title.

Tuesday, May 11th, 2021

Work at Clearleft

A little while back, I wrote about how much I like the job description of a design engineer. I still have issues with the “engineer” part, but overall it’s a great way to describe a front-end developer who works on the front of the front end: the outputs that end users interact with: HTML, CSS, and JavaScript. If it’s delivered in a web browser, then it’s design engineering.

Perhaps you also prefer the front of the front end to the back of the front end. Perhaps you also like to spend your time thinking about resilience, performance, and accessibility rather than build pipelines and frameworks. Perhaps you’d like to work with like-minded people.

Clearleft is hiring a midweight design engineer. Perhaps it’s you.

If you’d like to use your development talents in the service of good design, you should apply. And remember, you’d be working for yourself: Clearleft is an employee-owned agency.

You don’t have to be based in Brighton. You can work remotely, although we’re expecting that a monthly face-to-face gathering will become the norm after The Situation ends. So if you’re based somewhere like London, that would work out nicely. That said, if you’re based somewhere like London, this might also be the ideal opportunity to make a move to the seaside.

You do have to be eligible to work in the UK. Alas, that pool has shrunk somewhat. Thanks, Brexit.

Perhaps you think you’re not qualified. Apply anyway. You’ve got nothing to lose.

Perhaps this role isn’t for you, but you know someone who might fit the bill. Please tell them. Spread the word.

We’d especially love to hear from people under-represented in design and technology.

Come and work with us.

Thursday, April 22nd, 2021

Midweight Design Engineer | Clearleft

Want to work with me? If so, come and be a design engineer at Clearleft!

What’s a design engineer? A front-end developer at the front of the front end who values accessibility, performance, and progressive enhancement.

We’re looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production to join our friendly and supportive team in the heart of Brighton.

Even if this isn’t for you, please spread the word …especially to potential candidates who aren’t mediocre middle-aged white dudes (I’ve already got that demographic covered).

Tuesday, February 23rd, 2021

239: New CSS Tricks and Design Engineers | CSS-Tricks

We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.

Friday, February 19th, 2021

Design Engineering - Snook.ca

Here’s a seven-year old post by Snook—this design engineer thing is not new.

Design engineer

It’s been just over two years since Chris wrote his magnum opus about The Great Divide. It really resonated with me, and a lot of other people.

The crux of it is that the phrase “front-end development” has become so broad and applies to so many things, that it has effectively lost its usefulness:

Two front-end developers are sitting at a bar. They have nothing to talk about.

Brad nailed the differences in responsibilities when he described them as front-of-the-front-end and back-of-the-front-end web development:

A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.

A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.

In my experience, the term “full stack developer” is often self-applied by back-of-the-front-end developers who perhaps underestimate the complexity of front-of-the-front development.

Me, I’m very much a front-of-the-front developer. And the dev work we do at Clearleft very much falls into that realm.

This division of roles and responsibilities reminds me of a decision we made in the founding days of Clearleft. Would we attempt to be a full-service agency, delivering everything from design to launch? Or would we specialise? We decided to specialise, doubling down on UX design, which was at the time an under-served area. But we still decided to do front-end development. We felt that working with the materials of the web would allow us to deliver better UX.

We made a conscious decision not to do back-end development. Partly it was a question of scale. If you were a back-end shop, you probably had to double down on one stack: PHP or Ruby or Python. We didn’t want to have to turn away any clients based on their tech stack. Of course this meant that we had to partner with other agencies that specialised in those stacks, and that’s what we did—we had trusted partners for Drupal development, Rails development, Wordpress development, and so on.

The world of front-end development didn’t have that kind of fragmentation. The only real split at the time was between Flash agencies and web standards (HTML, CSS, and JavaScript).

Overall, our decision to avoid back-end development stood us in good stead. There were plenty of challenges though. We had to learn how to avoid “throwing stuff over the wall” at whoever would be doing the final back-end implementation. I think that’s why we latched on to design systems so early. It was clearly a better deliverable for the people building the final site—much better than mock-ups or pages.

Avoiding back-end development meant we also avoided long-term lock-in with maintainence, security, hosting, and so on. It might sound strange for an agency to actively avoid long-term revenue streams, but at Clearleft it’s always been our philosophy to make ourselves redundant. We want to give our clients everything they need—both in terms of deliverables and knowledge—so that they aren’t dependent on us.

That all worked great as long as there was a clear distinction between front-end development and back-end development. Front-end development was anything that happened in a browser. Back-end development was anything that happened on the server.

But as the waters muddied and complex business logic migrated from the server to the client, our offering became harder to clarify. We’d tell clients that we did front-end development (meaning we’d supply them with components formed of HTML, CSS, and JavaScript) and they might expect us to write application logic in React.

That’s why Brad’s framing resonated with me. Clearleft does front-of-front-end development, but we liaise with our clients’ back-of-the-front-end developers. In fact, that bridging work—between design and implementation—is where devs at Clearleft shine.

As much as I can relate to the term front-of-front-end, it doesn’t exactly roll off the tongue. I don’t expect it to be anyone’s job title anytime soon.

That’s why I was so excited by the term “design engineer,” which I think I first heard from Natalya Shelburne. There’s even a book about it and the job description sounds very much like the front-of-the-front-end work but with a heavy emphasis on the collaboration and translation between design and implementation. As Trys puts it:

What I love about the name “Design Engineer”, is that it’s entirely focused on the handshake between those two other roles.

There’s no mention of UI, CSS, front-end, design systems, documentation, prototyping, tooling or any ‘hard’ skills that could be used in the role itself.

Trys has been doing some soul-searching and has come to the conclusion “I think I might be a design engineer…”. He has also written on the Clearleft blog about how well the term describes design and development at Clearleft.

Personally, I’m not a fan of using the term “engineer” to refer to anyone who isn’t actually a qualified engineer—I explain why in my talk Building—but I accept that that particular ship has sailed. And the term “design developer” just sounds odd. So I’m all in using the term “design engineer”.

I can imagine this phrase being used in a job ad. It could also be attached to levels: a junior design engineer, a mid-level design engineer, a senior design engineer; each level having different mixes of code and collaboration (maybe a head of design enginering never writes any code).

Trys has written a whole series of posts on the nitty-gritty work involved in design engineering. I highly recommend reading all of them:

Tuesday, February 16th, 2021

Front-of-the-front-end and back-of-the-front-end web development | Brad Frost

These definitions work for me:

A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.

A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.

Thursday, October 8th, 2020

The Widening Responsibility for Front-End Developers | CSS-Tricks

Chris shares his thoughts on the ever-widening skillset required of a so-called front-end developer.

Interestingly, the skillset he mentions half way through (which is what front-end devs used to need to know) really appeals to me: accessibility, performance, responsiveness, progressive enhancement. But the list that covers modern front-end dev sounds more like a different mindset entirely: APIs, Content Management Systems, business logic …the back of the front end.

And Chris doesn’t even touch on the build processes that front-end devs are expected to be familiar with: version control, build pipelines, package management, and all that crap.

I wish we could return to this:

The bigger picture is that as long as the job is building websites, front-enders are focused on the browser.

Friday, August 28th, 2020

Why you should hire a frontend developer - Technology in government

This is a really good description of the role of a front-end developer.

That’s front end, not full stack.

Thursday, August 6th, 2020

Monday, May 4th, 2020

ongoing by Tim Bray · Bye, Amazon

May 1st was my last day as a VP and Distinguished Engineer at Amazon Web Services, after five years and five months of rewarding fun. I quit in dismay at Amazon firing whistleblowers who were making noise about warehouse employees frightened of Covid-19.

Fair play, Tim Bray!

The victims weren’t abstract entities but real people; here are some of their names: Courtney Bowden, Gerald Bryson, Maren Costa, Emily Cunningham, Bashir Mohammed, and Chris Smalls.

I’m sure it’s a coincidence that every one of them is a person of color, a woman, or both. Right?

Monday, November 11th, 2019

Don’t quit your day job: the benefits of being a ‘bifurcator’ | Aeon Essays

Here, then, is my speculation. Work is something we struggle to get and strive to keep. We love-hate it (usually not in equal measure). Sometimes it seems meaningless. I’m told this is the case even for surgeons, teachers and disaster-relief workers: those with jobs whose worth seems indisputable. For the mere facilitators, the obscure cogs in the machinery of the modern economy whose precise function and value it takes some effort to ascertain, the meaning in what we do often seems particularly elusive (I should know). I contend, however, that while our lives need to be meaningful, our work does not; it only has to be honest and useful. And if someone is voluntarily paying you to do something, it’s probably useful at least to them.

Thursday, August 1st, 2019

Ooops, I guess we’re full-stack developers now.

Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.

Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.

It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry

Tuesday, May 21st, 2019

What Does it Mean to Be “Full Stack”? | CSS-Tricks

I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills.

Thursday, May 9th, 2019

Head’s role

I have a bittersweet feeling today. Danielle is moving on from Clearleft.

I used to get really down when people left. Over time I’ve learned not to take it as such a bad thing. I mean, of course it’s sad when someone moves on, but for them, it’s exciting. And I should be sharing in that excitement, not putting a damper on it.

Besides, people tend to stay at Clearleft for years and years—in the tech world, that’s unheard of. So it’s not really so terrible when they decide to head out to pastures new. They’ll always be Clearlefties. Just look at the lovely parting words from Harry, Paul, Ellen, and Ben:

Working at Clearleft was one of the best decisions I ever made. 6 years of some work that I’m most proud of, amongst some of the finest thinkers I’ve ever met.

(Side note: I’ve been thinking about starting a podcast where I chat to ex-Clearlefties. We could reflect on the past, look to the future, and generally just have a catch-up. Would that be self indulgent or interesting? Let me know what you think.)

So of course I’m going to miss working with Danielle, but as with other former ‘lefties, I’m genuinely excited to see what happens next for her. Clearleft has had an excellent three years of her time and now it’s another company’s turn.

In the spirit of “one door closes, another opens,” Danielle’s departure creates an opportunity for someone else. Fancy working at Clearleft? Well, we’re looking for a head of front-end development.

Do you remember back at the start of the year when we were hiring a front-end developer, and I wrote about writing job postings?

My first instinct was to look at other job ads and take my cue from them. But, let’s face it, most job ads are badly written, and prone to turning into laundry lists. So I decided to just write like I normally would. You know, like a human.

That worked out really well. We ended up hiring the ridiculously talented Trys Mudford. Success!

So I’ve taken the same approach with this job ad. I’ve tried to paint as clear and honest a picture as I can of what this role would entail. Like it says, there are three main parts to the job:

  • business support,
  • technical leadership, and
  • professional development.

Now, I could easily imagine someone reading the job description and thinking, “Nope! Not for me.” Let’s face it: There Will Be Meetings. And a whole lotta context switching:

Within the course of one day, you might go from thinking about thorny code problems to helping someone on your team with their career plans to figuring out how to land new business in a previously uncharted area of technology.

I can equally imagine someone reading that and thinking “Yes! This is what I’ve been waiting for.”

Oh, and in case you’re wondering why I’m not taking this role …well, in the short term, I will for a while, but I’d consider myself qualified for maybe one third to one half of the required tasks. Yes, I can handle the professional development side of things (in fact, I really, really enjoy that). I can handle some of the technical leadership stuff—if we’re talking about HTML, CSS, JavaScript, accessibility, and performance. But all of the back-of-the-front-end stuff—build tools, libraries, toolchains—is beyond me. And I think I’d be rubbish at the business support stuff, mostly because that doesn’t excite me much. But maybe it excites you! If so, you should apply.

I can picture a few scenarios where this role could be the ideal career move…

Suppose you’re a lead developer at a product company. You enjoy leading a team of devs, and you like setting the technical direction when it comes to the tools and techniques being used. But maybe you’re frustrated by always working on the same product with the same tech stack. The agency world, where every project is different, might be exactly what you’re looking for.

Or maybe you’re an accomplished and experienced front-end developer, freelancing and contracting for years. Perhaps you’re less enamoured with being so hands-on with the code all the time. Maybe you’ve realised that what you really enjoy is solving problems and evaluating techologies, and you’d be absolutely fine with having someone else take care of the implementation. Moving into a lead role like this might be the perfect way to make the best use of your time and have more impact with your decisions.

You get the idea. If any of this is sounding intriguing to you, you should definitely apply for the role. What do you have to lose?

Also, as it says in the job ad:

If you’re from a group that is under-represented in tech, please don’t hesitate to get in touch.

Friday, April 5th, 2019

Why Computer Programmers Should Stop Calling Themselves Engineers - The Atlantic

This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:

“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.

Wednesday, March 6th, 2019

The “Backendification” of Frontend Development – Hacker Noon

Are many of the modern frontend tools and practices just technical debt in disguise?

Ooh, good question!

Tuesday, March 5th, 2019

How to Think Like a Front-End Developer by Chris Coyier

Alright! It’s day two of An Event Apart in Seattle. The first speaker of the day is Chris Coyier. His talk is called How to Think Like a Front-End Developer. From the website:

The job title “front-end developer” is very real: job boards around the world confirm that. But what is that job, exactly? What do you need to know to do it? You might think those answers are pretty cut and dried, but they’re anything but; front-end development is going through something of an identity crisis. In this engaging talk, Chris will explore this identity through the lens of someone who has self-identified as a front-end developer for a few decades, but more interestingly, through many conversations he’s had with other successful front-end developers. You’ll see just how differently this job can be done and how differently people and companies can think of this role—not just for the sake of doing so, but because you’ll learn to be better at your own jobs by understanding how other people are good at theirs.

I’m going to see if I can keep up with Chris’s frenetic pace…

Chris has his own thoughts about what front-end dev is but he wants to share other ideas too. First of all, some grammar:

I work as a front-end developer.

I work on the front end.

Those are correct. These are not:

I work as a front end developer.

I work on the front-end.

And this is just not a word:

Frontend.

Lots of people are hiring front-end developers. So it’s definitely a job and a common job title. But what does it mean. Chris and Dave talked to eight different people on their Shop Talk Show podcast. Some highlights:

Eric feels that the term “front-end developer” is newer than the CSS Zen Garden. Everyone was a webmaster, or as we’d say now, a full-stack developer. But if someone back then used the term “front-end developer”, he’d know what it meant.

Mina says it deals with things you can see. If it’s a user-facing interface, that’s front-end development.

Trent says that he thinks of himself as a web designer and web builder. He doesn’t feel he has the deep expertise of a developer, and yet he spends all of his time in the browser.

So our job is in the browser. You deal with the browser (moreso than other roles). And by the way, there are a lot of browsers out there.

Maybe the user is what differentiates front-end work. Monica says that a back-end developer is allowed not to care about the user if their job is putting a database together. It’s totally fine not to call yourself a front-end developer, but if you do, you need to care about the user.

There are tons of different devices and browsers. It’s overwhelming. So we just gave up.

So, a front-end developer:

  • Is a job and a job title.
  • It deals with browsers, devices, and users.
  • But what skills does it involve?

It’s taken for granted that you can use a computer. There’s also the soft skills of interacting with co-workers. Then there are the language-specific core skills. Finally, there are the bonus skills—all the stuff that makes you you.

Core skills

The languages you need to strongly understand to read, write and maintain them.

HTML and CSS. Definitely. You don’t come across front-end developers who don’t do those languages. But what about JavaScript?

Eric says it’s fine if you know lots of JavaScript but it’s also fine if you don’t write everything from scratch. But you can’t be oblivious to it. You need to understand what it can do.

So let’s put JavaScript into the bucket of core skills too.

Peggy believes that as a front-end developer you need to have a basic proficiency in accessibility too. This is, after all, about user-facing interfaces.

Bonus skills

The Figma team have a somewhat over-engineered graphic of all the skillsets that people might have, between “baseline” and “supplementary”.

Perhaps we all share a common trunk of skills, and then we branch in different directions.

Right now though, it feels like front-end development is having an identity crisis. It’s all about JavaScript, which is eating the planet.

JavaScript

JavaScript is crazy popular now. It’s unignorable. Yes, it’s the language in the browser, but now it’s also the language in loads of other places too.

Steven Davis says maybe we need to fork the term front-end development. Maybe we need to have UX engineers and JavaScript engineers. Can one person be great at both? Maybe the trunk of skills forks in two very different directions.

Vernon Joyce called this an identity crisis. The concepts in JavaScript frameworks are very alien to people with a background in HTML, CSS, and basic interactive JavaScript.

You could imagine two people called front-end developers meeting, and having nothing in common to talk about. Maybe sports.

Brad says he doesn’t want to be configuring build tools. He thinks of himself as being at the front of front-end development, whereas other people are at the back of front-end development.

This divide is super frustrating to people right now.

Hiring

Michael Schnarnagl brings up the point about how it’s affecting hiring. Back-end developers are being replaced with JavaScript engineers. Lots of things that used to be back-end tasks are now happening on the client side. Component-driven design, site-level architecture, routing, getting data from the back end, mutating data, talking to APIs, and managing state—all of those things are now largely a front-end concern.

Let’s look at CodePen. There’s a little heart icon on each pen. It’s an icon component. And the combination of the heart and the overall count is also a component. And the bar of items altogether—that’s also a component. And the pen it sits under is a component. And the page it’s in is a component. And the URL for that page is a component. Now the whole site is a front-end developer’s concern.

In the past, a front-end developer would ask a back-end developer for an API endpoint. Now with GraphQL, the front-end developer can craft a query to get exactly what they need. Sure, the GraphQL stuff had to be set up in the first place, but that’s one-time task. Once it’s set up, the front-end developer has everything they need.

All the old work hasn’t gone away either. Semantics, accessibility, styling—that’s still the work of a front-end developer as well as all of the new stuff listed above.

Hiring is a big part of this. Lara Schenk talks about going for an interview where she met 90% of the skills listed. Then in an interview, she was asked to do a fizzbuzz test. That’s not the way that Lara thinks. She would’ve been great for that job, but this single task derailed her. She wrote about it, and got snarky comments from people who thought she should’ve been able to do the task. But Lara’s main point was the mismatch between what was advertised and what was actually being hired for.

You see a job posting for front-end developer. Who is that for? Is it for someone into React, webpack, and GraphQL? Or is it for someone into SVG, interaction design, and accessibility? They’re both front-end developers. And remember, they can learn one another’s skills, but when it comes to hiring, it has to be about the skills people have right now.

Peggy talks about how specialised your work can be. You can specialise in SVG. You can specialise in APIs and data.

We’re probably not going to solve this right now. The hiring part is definitely the worst part right now. One solution is to use plain language in job posts. Make it clear what you’re looking for right now and explain what background you’re coming from. Use words instead of a laundry list of requirements.

Heydon Pickering talks about full-stack developers. Their core skills are hardcore computer science skills.

Brad Frost concurs. It tends not to be the other way around. The output tends to be the badly-sketched front of the horse.

Even if there is a divide, that doesn’t absolve any of us from doing a good job. That’s true whether it’s computer science tasks or markup and CSS.

Despite the divide, performance, accessibility, and user experience are all our jobs.

Maybe this term “front-end developer” needs rethinking.

The brain game

Let’s peak into the minds of very different front-end developers. Chris and Dave went to Dribbble, pulled up a bunch of designs and put them in front of their guests on the Shop Talk Show.

Here’s a design of a page.

  • Brad looks at the design and sees a lot of components of different sizes and complexity.
  • Mina sees a bunch of media objects.
  • Eric sees HTML structures. That’s a heading. That’s a list. Over there is an unordered list.
  • Sam sees a lot of typography. She sees a type system.
  • Trent immediately starts thinking about how the design is supposed to work in different screen sizes.

Here’s a different, more image-heavy design.

  • Mina would love to tackle the animations.
  • Trent sees interesting textures and noise. He wonders how he could achieve those effects without exporting giant image files.
  • Brad, unsurprisingly, sees components, even in a seemingly bespoke layout.
  • Eric immediately sees a lot of SVG.
  • Sam needs to know what the HTML is.

Here’s a more geometric design.

  • Sam is drawn to the typography.
  • Mina sees an opportunity to use writing modes.
  • Trent sees a design that would reflow and reshape itself well.
  • Eric sees something with writing mode, grid, and custom fonts.

Here’s a financial mobile UI.

  • Trent wants to run it through a colour-contrast analyser, and he wants to know if the font size is too small.

Here’s a crazy festival website.

  • Mina wonders if it needs a background video, but worries about the performance.

Here’s an on-trend mobile design.

  • Monica sees something that looks like every other website.
  • Ben wonders whether it will work in other parts of the world. How will the interactions work? Separate pages or transitions? How will it feel?

Here’s an image-heavy design.

  • Monica wonders about the priority of which images to load first.

Here’s an extreme navigation with big images.

  • Ben worries about the performance on slow connections.
  • Monica gets stressed out about how much happens when you just click on a link.
  • Peggy sees something static and imagines using Gatsby for it.

Here’s a design that’s map-based.

  • Ben worries about the size of the touch targets.
  • Monica sees an opportunity to use SVGs.

Here’s a card UI.

  • Ben wonders what the browser support is. Can we use CSS grid or do we have to use something older?
  • Monica worries that this needs drag’n’drop. Now you’ve got a nightmare scenario.

Chris has been thinking about and writing about this topic of what makes someone a front-end developer, and what makes someone a good front-end developer. The debate will continue…