Why Pantone Colors Are So Expensive | So Expensive | Business Insider

Pantone has been the industry-standard color language for 60 years. Its tools ensure that color looks the same, no matter where in the world it’s printed. If you design or print physical products, there’s no escaping Pantone. But its products are expensive; some cost over $1,000. Now, designers frustrated with Pantone’s level of control are asking if there’s a better way. So, why are Pantone colors so expensive? And after decades, can anything replace them?

https://youtu.be/xnpyTNK4U9U

#pantone #design #grafika

Kurła kiedyś to było

Wszystkie działają. Tylko w Nokia E90 mikrofon nie działa znany problem w nich. Padalec z allegro mnie oszukał.

#telefony #technologia #design

#design #sztuka #niewiemjaktootagowac

Dalsze odkrywanie trybu pracy w firmie produktowej #it

Przez ostatni rok pracowałem z zespołem, gdzie dwie główne devki były, w mojej ocenie, dość nielotne.

Po każdym refinemencie jak już wiedziałem jakie są wymagania zabierałem się za design. Moje pliki z figmy zawsze zawierają mockupy poukładane tak że odzwierciedlają ścieżkę użytkownika i stany komponentów (jakieś errory, empty, active, hover itp.) tak żeby frontend dev miał wszystko na tacy. Czasem nawet robiłem klikalny prototyp i nagrywałem to żeby dev mógł łatwo obejrzeć jak wygląda happy path. Dodatkowo każda ścieżka posiada tytuł z linkiem do taska w jirze w którzym są kryteria akceptacji (np. dodawanie do koszyka JP-2137) tak że jak się czegoś nie rozumie z mockupów to można łatwo znaleźć dodatkowe informacje. Na każdym design handoverze tłumaczę dlaczego tak coś zostało zaprojektowane, w oparciu o co, i robię często dwie wersje: minimum z której nie da się już nic wywalić żeby nie zepsuć ficzerka, oraz pożądaną.

I jak przychodziło do implementacji, to i tak te devki potrafiły miesiąc po klepnięciu wszystkiego zadawać pytania "a czemu tak? a mi się podoba inaczej" albo "a jak to działa?", "a po co ten przycisk?". Mając dokładne mockupy, kryteria akceptacji i spotkanie z handoverem.

Przełknąłem to, nauczyłem się z tym żyć.

Ale przyszedłem do drugiego zespołu i jest to samo. Porozmawiałem w zespole o tym, bo pomyślałem że może to ja coś za dużo zakręciłem i się w tym gubią. Pogadałem ze znajomymi devami z innych firm żeby dali mi feedback czy takie coś pozwalałoby im mieć wiedzę co zrobić i jak i wychodziło że bez problemu.

I wtedy eureka, dotarło do mnie.

Otóż wczoraj przekazałem kolejne mockupy i dosłownie minutę później pisze do mnie PO projektu:

-Siema Maciek, bo Tomek jest zblokowany z taskiem, nie może rozkminić o co chodzi w tych mockupach

-Tak jak mówiłem na spotkaniu chodzi o blablabla, co jest dodatkowo opisane w tasku blablabla

i zatrzymałem się bo raz że wkurzyłem się że znów muszę to powtarzać, a dwa dlaczego ten dev sam do mnie nie napisze

I sobie pomyślałem, że jakby ten dev od razu wziął się do pracy, to wyszłoby że albo

a) zrobiłby to szybko i miał czas na dodatkową wrzutkę

b) jakby chciał to porobić na chillu to wyszłoby że robi to dłużej niż przewidywano i musiałby się tłumaczyć czemu

tak źle i tak niedobrze.

więc co robią devi?

W d⁎⁎ie mają te taski, mockupy, handovery itp. Oni już z góry wiedzą, że jak przyjdzie do implementacji to napiszą na priv (no bo wiadomo że nie na kanale zespołu) do PO czy innego BA że brakuje im danych do rozpoczęcia pracy, wrzucają taska na "blocked" i mają labę, bo wtedy druga osoba musi te informacje zdobyć. Zanim ten PO czy BA ogarnie o co chodzi i napisze do mnie, zanim ja mu odpiszę, zanim on upewni się że faktycznie wszystko jest i zanim odpisze devowi mija jakieś pół dnia, a może nawet i kilka dni jak BA uzna że może lepiej zrobić spotkanko. W tym czasie można mówić "no ja jestem zblokowany z tym taskiem" i mieć wywalone.

I podstawą tu jest pisanie na priv, nie bezpośrednio do ludzi którzy mogą ci pomóc, tylko znaleźć sobie takich który wielbią się w byciu potrzebnymi.

Serio, przejście z software house do firmy produktowej to nadal jest dla mnie odkrywanie nowych poziomów opierdalactwa i spychologii.

#pracbaza #pracait #korposwiat #design

Why Fonts Look Better on Mac Than on Windows?

https://youtu.be/9bOw67tXfaM

#apple #ux #design #typografia

Serwis kawowy "Dorota" zaprojektowany przez Lubomira Tomaszewskiego dla Instytutu Wzornictwa Przemysłowego, 1961 rok.

#sztuka #kawa #design

https://streamable.com/yqrkmo

Jak dla mnie to design lat 50 jest świetny!

Nie zwykle płytki łazienkowe.

#design #sztuka #kosmos #50style #heheszki

Korzysta ktoś tutaj z FontForge? Pokonał mnie ten program. Jak zmieniłem "Ó" to zmienia mi się "O" i na odwrót. Nie wiem jak to poprawić:(

#fontforge #grafika #grafikakomputerowa #dtp #poligrafia #design #fonty #czcionki

Kierownica w nowym DS No8, nie jestem przekonany

#motoryzacja #citroen #ds #design

Przed państwem szczyt w dziedzinie #design

Wywalamy klasyczne zegary, bierzemy odrzuty od producentów smartfonów, wstawiamy prostokątną zaślepkę i cyk, pora na CS

Ponoć #alfaromeo

#motoryzacja #samochody #heheszki

W ogóle pomijają samą ocenę czy to wygląda dobrze czy źle, to co szanuję to to, że apple robiąc ten redesign wyszło odpowiadając na pytanie jak będą wyglądały interfejsy w przyszłości i szkło i taki ui to jest temat wizualizacjach większości sci-fi pokazującego futurystyczne telefony nawet nawet w jakiś filmach krótkometrażowych z tanim budżetem - więc dość popularna wizja. Ale największym plusem dla appla jest to, że to jest świeży design, bo już od 15 lat wszystko szło w minimalizm, dopiero jakiś czas temu trochę odżyły gradienty więc może to nie jest najlepszy plan i pomysł na przyszłe interfejsy, ale jest świeży i nie kolejna iteracja płaskich ikonek która byłaby bezpieczna.

#apple #ios #design #liquidglass

#zzr #design

#design #zzr

Każdy talk na temat UX na każdej konfie czy meetupie

1. Tytuł talka zaczyna się, lub zawiera pytanie z "how"

2. Blablabla nikt nas nie słucha, zły PM, blablabla

3. Bez nas ten produkt zdechnie

4. opis problemu z którym zderzył się autor

5. Suspens przez przejściem do wniosków

6. Wnioski: DO THE RESEARCH

7. dziękuję

#ux #design