Think before you npm install

instead of doing it automatically every time, let’s take the time to pause and consider whether we really need to.

We need to identify exploitation. While there are some gleeful Full Stack Developers, many are computer scientists given too many responsibilities, and over things for which they are not willing or qualified to be held accountable.We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.We need to revisit the separation of concerns principle. We simply can’t afford for people to have to know everything just to do something. It’s good that we conceptualize designs in terms of self-contained components now, but that can be a mental model without being a technology-specific land-grab.Most of all, we need to educate people who don’t code at all just how many different things different types of code can do, and how different each is to understand and write. Hopefully, this way, more of us will be writing the kind of code that suits us best, and not spending our time anxious and demoralized because we don’t know what we’re doing, or we simply have too much on our plate. That’s not to say that if you do take to JS, CSS, HTML, SQL, and C# you shouldn’t be writing all of them if you‘d like to and you have enough time!

unnecessary rework of both design and code is nearly guaranteed, and the monetary costs are high. The Dev Ops Research & Assessment Group calculates that for a medium-sized business at a medium level of technical performance, upwards of 37.8M is lost to unnecessary rework each year.

Forrester Research quantified how much cheaper it is to find and fix problems earlier in the build process, with costs 30 times higher if fixes happen after work ships.

starting with a Double Diamond design process, then shifting to the build phase with iterative engineering sprints:In No Handoff, discovery, and development phases happen in iterations with the involvement of an interdisciplinary team:Discovery is not conducted solely by the UX and Design team, nor compressed into a single sprint. It takes place in cycles as the team tests the prototype with users and gains more insights.Definition is when decisions are made on what to prioritize, and what to work on next. Basing these decisions on the latest rounds of feedback further reduces risk.During Develop/Deliver stages, both design and functionality emerge side by side, informing one another. In this way, designers avoid specifying needlessly expensive directions or components or designing things in detail that don’t have value or won't be built. Engineers avoid building functionality ahead of validated business needs, and also avoid unnecessary rework due to unexpected redesigns.

This iterative process clearly reduces risk, but other benefits are more surprising.Teams develop a shared vocabulary, tooling, and cadence, closing the gap between engineering and product.The voice of the end user is elevated; design and function co-emerge based on real usability needs. Traditional project handoff precludes the possibility of continuous listening, while the No Handoff Method is built around it.Designers are working directly on the product design, not on throwaway artifacts.Onboarding is happening continuously with end users during frequent testing phases. This further reduces the risk of users (or other stakeholders) unexpectedly rejecting the end results.Iteration and frequent user testing can give Marketing and Sales teams invaluable insights in advance of releases.An atmosphere of trust is built as developers and designers become comfortable openly sharing work earlier in the ideation phase without fear of reprisal for mistakes or imperfections.Leadership and end-users trust that they are being heard, too, because they see and experience the results of their feedback in future iterations.Trust allows teams to develop a culture of learning, continuously improving the product.

Design decisions have to be informed by technical implementations and its limitations. There is no universal language around design patterns and their interaction design either. And not every design detail can be implemented in an accessible and performant way. This is why beautiful mock-ups turn into painfully slow and inaccessible monsters.

Content out Grid system design should begin with a constraint. Something that is knowable and unchangeable.

as soon as a page is published online, we can’t predict how someone experiences it. Their screen might be wildly smaller or larger than mine, sure. But any number of factors might change the user’s experience: their network might be punishingly slow; their data plan could be stringently capped; they may use their voice to interact with my design; they may not see the screen like I do. In other words, we’ve never had any kind of control on the Web. And that lack of control can feel scary, sure — but if we approach it properly, it can be incredibly powerful.

creative work is much better suited by a prototyping demo loop or a hot-potato process to overcome the tension between design and development

Anyways. If you do find yourself stuck on an assembly line, I recommend a good set of headphones and chill lo-fi beats or whatever music helps you focus.