In technical context leaving unknowns with unknown boundaries behind is an approach that makes it hard to assess next actions in error cases, but even more importantly it makes the future system design work rooted on uncertainty.
To me that is blocker to my thinking. I really need to understand the impact of leaving something behind before continuing. I’d likely do everything in my power to remove that unknown from current state for the sake of sanity.
I am interested if someone has written a document/post/article that approaches ”web needs simplification” in current context in holistic manner. E.g. Considering energy consumption, development costs, tooling complexity, state of web standards, private and public industry domain needs etc.
I personally see different problems in many of the areas, but I’d like to know if someone has already organised these topics.
”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.
- 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.
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
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.
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.
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.
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.
To me that is blocker to my thinking. I really need to understand the impact of leaving something behind before continuing. I’d likely do everything in my power to remove that unknown from current state for the sake of sanity.