An example — creating a design for developer documentation that features code snippets. Like the "Example Response" on https://stripe.com/docs/api/node#balance_object

If you're working in any templating or component framework you should create a reusable component for something like a button. Then you only write the classes once in the component and then in something like React, call <Button> everywhere else. This also provides a source of truth.

Try using it in a project before providing the "hard to decipher" argument. Sure, there are a lot of classes there, but you can see every style that is being applied – right in the markup. I'd argue that is easier than parsing through markup and stylesheets and dealing with inheritance issues.

This looks like an incredible system. I had been working on a framework that is similar to this (https://github.com/decent-css/decent) for about a year because of the lack of configuration available with Basscss and Tachyons.

I transitioned to using functional CSS about two years ago and haven't looked back. Once you break the mindset of how we used to write CSS, it becomes incredibly quick to build good looking things — pair that with a component-based framework like React or Vue and the possibilities are endless.

Was just thinking the same thing.

All of Adam's points are valid. His comment wasn't so much about how the delete but looks or should look, but about the danger of making a final deduction or suggestion from a test that doesn't include a major factor of the interaction – which is the styling that is specific to the native iOS list.

While your test does suggest that explicitly displaying the delete icon results in more successful completions of the task in general, it doesn't answer whether this pattern results in more successes when the prototype is styled more like an iOS application.

In other words correlation ≠ causation.

There are definitely some good points in this article.

But. Can we please not use titles that are imperatives/commands - "Stop doing this" or "Start doing this". Even if your article is well-written and supported, I don't want you telling me what to do. I'll study the information and insights and determine if it fits in with my workflow, my experiences, my research, and my beliefs.

Maybe a bit of a rant, but it seems that everyone and their brother is writing an article that is either telling me do something or stop doing something.

The visual design is awesome!! Some of the buttons are small/hard to target tho - ie. I went to click on the menu icon and accidentally hit the back to top and was scrolled allll the way back to the top.

I felt the same way. "Designing in the browser" sounds great, especially to stakeholders, but there's a huge barrier in between the thought and its representation. When you sketch, wireframe, or design in Ps/Ai/Sketch the thought can be expressed pretty quickly, but in code, you have to figure out exactly how you might set something up to express the thought = big wrench in the process.

Plus once the code gets messy enough, you don't want to or simply can't change anything.

I've found that sketching and wireframing really helps lay the foundation. Then I go into a more solid visual design, but may start coding at this point - going back and forth between Ps/Ai/Sketch and code. Getting into code does help getting a feel for interactions. Ae and Ps are great for showcasing animation, but in this case, it's way quicker to just code them.