- actually test the UI (different devices, browsers, viewports, scenarios)
- reserve APPROPRIATE time to test UI
- reserve APPRORIATE time to fix the issues
- have designer in tight loop
- have systematic approach to track issues
- test with users
- aim to apply fixes asap so that the fixes gets tested as well
Biggest single factor causing issues is to start late. The time will run out if the styling setup is not robust, it depends on some questionable conventions or libraries, or is simply hacked together.
It is not that complicated, but it is most certainly difficult to do magic tricks late in the development.
React itself is not a root cause. I believe the fundamental cause is a mix of skill issues, lack of knowledge, quality ambitions and time management.
> Biggest single factor causing issues is to start late.
This entirely depends on the dev team working on it and the complexity of what's being asked for. As a developer, I'd rather start late on simple ideas than start early on incomplete and overly complex requirements.
I've seen plenty of projects be absolutely destroyed by product managers and designers with main character syndrome and their own lack of attention to detail and being entirely unresponsive to or flat out inexperienced at answering the technical questions from developers.
Those design decisions are sometimes even late and only mentioned after dev has started. That's completely unacceptable on any project. Requirements and designs are their own intermediate result and demand just as much finality as the product itself. Every revision will erode the final product and mess up a deadline. Developers should not be along for the ride with indecisive designers. Go to the developers with a completed vision and no stone unturned and you will have the best results. Level of experience throughout the project must be equal.
The implementation details are far more important to the overall UX and polish of the result than the visual design. The implementation details can't be ignored or you risk an uncoordinated shit show.
”Start late” in relation to paying attention to details, testing UI and other quality aspects that are not visible in the beginning. In simple terms: budget some time to handle unknowns. Or at least some of them.
When it comes to the amount of upfront design needed…
…yes, everyone agree ”complete vision no stone unturned” is the optimal. That is easy ask.
In real life that is not possible, unless you are working with incredibly small scope OR without any schedule. I.e. not possible. Business with money involved? Just no.
Agree on level of experience. Experience usually helps a lot.
Unable to design and develop system with certain level of uncertainty and adaptability is the real tragedy.
I believe everyone should be interested on the possible routes ahead. Assuming one or two persons are able to foresee some unknowns is intellectually lazy. Expecting them to brainstorm it out to the detail infront of some whiteboard is just not how real life works.
> Unable to design and develop system with certain level of uncertainty and adaptability is the real tragedy.
I'm entirely willing to sound like a naive fool for saying this, but the tragedy from my perspective is business not willing to accept that the majority of the risk comes from letting people with less technical experience be in charge of people with more. That's just plain dysfunction and all too common. Many businesses waste so much money on scaling up their teams when they should be focused on hiring or training up the best.
You are not. As a dev I understand the temptation of Tailwind, but I don’t see the benefits really worth it in all cases where I see it’s used. Writing plain CSS just makes so much more sense in the long run.
Based on some experience (designer and developer), here’s some thoughts I currently have about them:
- high-level idea is usually understood, although mixed with design tooling
- practical usage rarely straightforward
- most of the activities are surface level and trivial
- required effort to maintain and develop often underestimated
- maturity level rarely reaches the potential
- ”component” is not an easy concept, especially in multi-product setting
- too often design driven, when implementation driven would make more sense
- generates meetings on many meta-dimensions
- not necessarily rewarding exercise for the maintainer due to various organisational and political challenges
- does not actually help on design-to-development e2e flow as much as advertised
- even with all the work put in, does not guarantee good product
You are getting it. Use less and smaller tools if possible. And if you're on Node 18, node comes with a watch mode built in that you can leverage.
You can alternatively use esbuild to handle the TypeScript compilation since it is faster than tsc for that, and just keep tsc around for the typechecker.
As a designer (UX focused, but technical as well), I have put a lot of effort to study prototyping in sw context.
I think prototype itself is fairly well understood as a noun, but how to approach the activity is not that well understood. I think it starts with what to prototype (scope/intent) and what to do with the outcome. This is where different viewpoints start to have their impact.
It is very common mindset not discard anything that has been done. Some cognitive biases are likely in effect here.
It is also common to attach additional intentions retroactively. E.g. it is totally ok to build UI prototype and to deviate drastically from the current state of things. Depends on the intention. Now, it is not hard to imagine a follow-up discussion that takes unfortunate turn at some point because the expectations for the activity does not match. The focus shifts from the main idea to defining what was not the idea. The value of the activity diminishes steadily. At worst, inexperienced prototypers might end up with a loundry list of changes to be done to meet the current state, confused about what just happened.
I think the main point of the article is valuable: be ready to stop and throwaway your prototype. Use it smartly. Find things you want to validate or just see, then be immediately ready to throw it away. Do not project additional things on to it. Use that energy towards the ”real thing”.
In the world of Figma/other prototypes there seems to float this idea that prototype has some fixed and standardized meaning. As an activity it has been bolted into different methodologies and tools, which is fine of course, but they are also taught, discussed and treates together with specs, requirements and other artifacts that serves different purpose. They communicate different things.
That’s it. In the end it is about communication. I think the great power of prototyping makes it also hard to use to it effectively. Personally, I think the best part of building a prototype is to throw it away. It is a milestone, the end. Almost always a success.
After trying almost everything I can imagine (probably twice) to manage my tasks and time I found the sweetspot from hybrid model of digital and analog. The system is rather simple: I write stuff to the paper (home and work) and then take a picture/scan with my phone. I use the appropriate cloud provider app depending on the context. Files are stored in chronological order.
I keep the current state on paper and whenever I need I just cleanup notes to the cloud and shred the papers.
The beauty of this is that I think I have finally got back the time that all these tools took from me. It was much simpler than I thought.
I do something similar for notes: I have an A4 whiteboard I basically always have with me at home. I pace around a lot while thinking and love writing on a physical something. Most ideas are short term, and can be erased, but for anything else, I snap a picture of the whiteboard.
Notes apps are laughably terrible, I hate limiting my stream of consciousness to a one dimensional line of characters. Worse is trying to do it with two thumbs on a smartphone.
I also think that storing everything with some arbitrary tag/folder model enforces the misconception that everything that was once created is equally important. Notes/todo apps don’t really address this.
Few points after reading the comments. From designer pov:
- Although the definition of a Design System is somewhat loose, it can be stated that Bootstrap is a NOT a design system.
- To reduce Design System to a branded collection of technical assets is simplistic. You are still not getting it.
- The general idea of Design Systems is much more than organising some components for one medium (web). The execution of the system might or might not be good.
- In order to do design (UX, UI, ...), you don't need to be "a designer". However, the fact that it is possible to use something like Bootstrap does not make your design (outcome) work automatically. More often that not, the work done by non-designer is not as good. The craft exists. Thinking that "the problem has been solved already" means you don't actually understand the full problem. Like with anything, some aspects are re-solved continuously. Maybe unnecessarily. Maybe not.
- For many it would probably be easier to think that all design is design. Any act of diminishing some aspect of design can be mirrored by asking yourself if you think your design tasks can be done by anyone not paying appropriate attention. E.g. if you are a programmer, imagine a random stakeholder would quickly put together your data models and API designs and call it a day. Would it work? Would it scale? Would it be enough? Maybe.
- Any design can be challenged. Complaining about stakeholders is lame. Check your argumentation skills and asses if you have actually challenged the design when you had the opportunity.
- focus on authoring robust CSS
- actually test the UI (different devices, browsers, viewports, scenarios)
- reserve APPROPRIATE time to test UI
- reserve APPRORIATE time to fix the issues
- have designer in tight loop
- have systematic approach to track issues
- test with users
- aim to apply fixes asap so that the fixes gets tested as well
Biggest single factor causing issues is to start late. The time will run out if the styling setup is not robust, it depends on some questionable conventions or libraries, or is simply hacked together.
It is not that complicated, but it is most certainly difficult to do magic tricks late in the development.
React itself is not a root cause. I believe the fundamental cause is a mix of skill issues, lack of knowledge, quality ambitions and time management.