2024年3月9日のブックマーク (5件)

  • 【便利tips】Figmaでデザインデータを作る時のイロハについてデザイナーに聞いてみた

    はじめに レバテック株式会社で主にサービスサイトのディレクターをしている山です! 普段はデザインシステムや、デザインの制作進行管理などをメインで担当しています。 レバテックでは、Figmaというデザインツールを用いて多くのメンバーがデザイン制作を行なっているんですが、いろんな人が各々のやり方でデザインデータを作成するので、属人的なズレがたくさん発生し、コミュニケーションコストや内部品質管理などの色々な問題が起きていました。 例 Auto LayoutとFrameが混在 コンポーネントのプロパティ名がバラバラ etc... 私自身、フロントエンドの理解はありつつもレバレジーズに入社してからFigmaを触り始めたため、社内のデザイナーにちょこちょこ質問を投げかけて勉強していました。当たり前に使っているtipsでも意外と「知らなかった」ような内容もたくさんあり、今回は私が「これは賢い!」と思っ

    【便利tips】Figmaでデザインデータを作る時のイロハについてデザイナーに聞いてみた
    tech0403
    tech0403 2024/03/09
  • Docker ハンズオン / docker-hands-on

    2024/03/07 【開発系エンジニアのためのDocker絵とき入門出版記念】著者と学ぶ Docker ハンズオン https://phper-oop.connpass.com/event/309942/ スライドで参考資料としているのは 開発系エンジニアのためのDocker絵とき入門…

    Docker ハンズオン / docker-hands-on
    tech0403
    tech0403 2024/03/09
  • 「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か?|moutend

    結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。

    「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か?|moutend
    tech0403
    tech0403 2024/03/09
  • AIを操る「プロンプトエンジニア」がAIによって駆逐されつつある

    「プロンプトエンジニアリング」は、意図した通りの出力を得るためにAIへの命令文であるプロンプトを調整する行為です。これまで、プロンプトエンジニアリングは人間のエンジニアによって行われてきましたが、プロンプトの作成自体にもAIを使用した方がパフォーマンスが向上するという研究結果が発表されました。 [2402.10949] The Unreasonable Effectiveness of Eccentric Automatic Prompts https://arxiv.org/abs/2402.10949 AI Prompt Engineering Is Dead - IEEE Spectrum https://spectrum.ieee.org/prompt-engineering-is-dead 2022年の秋にChatGPTが登場して以来、プロンプトを工夫することでAIの出力を改善し

    AIを操る「プロンプトエンジニア」がAIによって駆逐されつつある
    tech0403
    tech0403 2024/03/09
  • 『ベタープログラマ』 を読んだ

    『ベタープログラマ』を読んだので自分的に刺さった点をまとめる。 6章 航路を航行する⌗ 新たなメンバーが開発チームに参加する際にどのようにすれば速やかに生産的になることができるかについての章。 最善な策はすでにプロジェクトへの理解があるメンバーに導いてもらうこと。もしそれができなければ次のようなことを調べるとよい。 ソースの取得の容易さ⌗ ソースの取得がどれだけ簡単か。健全なプログラムはコードベース全体を得るための単一のチェックアウトのみを必要とする。 コードのビルドの容易さ⌗ 一般的でないツールにビルドが依存していないか コード自身に適切で簡単なドキュメンテーションがあるか 手作業なしで1つのコマンドでビルドを行うことができか コードの一部に取り組んでいるときにその部分だけをビルドできるか ビルド中に潜在的な問題を曖昧にしているかもしれない無数の警告が出ていないか テスト⌗ 単体テスト・

    『ベタープログラマ』 を読んだ
    tech0403
    tech0403 2024/03/09