There’s a zillion tools for User Experience and User Interface Design. Don’t take my word for it: a simple Google search for “what are the best tools for wireframing” (to take just one aspect of UX) leads you to endless pages of “The 20 best wireframe tools”, “The 14 Best Wireframe Tools”, “18 Best Wireframe Tools Compared (2020)”.

有用于用戶體驗和用戶界面設計的無數工具。 不要相信我的話：簡單的Google搜索“ 什么是最好的線框圖工具 ”(僅代表UX的一個方面)，您會無休止地瀏覽“ 20種最佳線框工具”，“ 14種最佳線框工具”。 “線框工具”，“比較18種最佳線框工具(2020年)”。

You’ll find names like Figma, Adobe XD, Sketch, or Axure RP but also the likes of TemplateToaster, Moqups, ProtoPie, Cacoo, Marvel, Gliffy and many, many more. They each have carefully listed pros and cons, and they all come with their avid defenders (and/or detractors).

您會發現諸如Figma，Adobe XD，Sketch或Axure RP之類的名稱，還有TemplateToaster，Moqups，ProtoPie，Cacoo，Marvel，Gliffy之類的名稱，等等。 他們每個人都有精心列出的利弊，而且都帶有自己的狂熱防守者(和/或批評者)。

It sometimes seems like we’re always in transition between tools: tempted by the shiny new features on the one hand –look at the wonderful things we’ll be able to do!– but held back by the cost of switching. Forever teetering between the Scylla of too early adoptership and the Charybdis of sunk cost fallacy (insert minute of silence for everyone that built their lives around Sketch and an entire shantytown of plugins only to realise Figma’s perhaps a better way to go forward).

有時似乎我們總是在工具之間轉換：一方面受閃亮的新功能的誘惑-看看我們將能夠做的奇妙事情！-但由于轉換成本而受阻。 在過早采用者的Scylla和沉沒的謬論的Charybdis之間永遠搖搖欲墜(對于在Sketch和整個插件貧民區生活的每個人都保持一分鐘的沉默，只是為了意識到Figma可能是一種更好的前進方式)。

I get it, I really do. When there’s something new I’m always the first one to try it out. But the older I get, the more I feel we risk losing our way in new tools and toolboxes and templates and methods. More and more, when I see the latest Tool Du Jour used by colleagues and co-workers, I get the impression we’re focusing too much on process and tools, and losing sight of the actual result we’re trying to achieve.

我明白了，我確實做到了。 當有新東西出現時，我總是第一個嘗試它的人。 但是，我年齡越大，我越有風險在新工具，工具箱，模板和方法中迷失方向。 越來越多地，當我看到同事和同事使用的最新Tool Du Jour工具時，我得到的印象是，我們過于關注流程和工具，而忽略了我們試圖實現的實際結果。

攻擊艦在獵戶座的肩膀上起火 (Attack ships on fire off the shoulder of Orion)

I’m an old, old man. I can scarcely believe it but I’ll be fifty very soon. In the words of Roy Batty: I’ve seen things.

我是一個老人，老人。 我簡直不敢相信，但是我很快就要五十歲了。 用羅伊·巴蒂(Roy Batty)的話說：我看過東西。

I have always been passionate about information and the tools to classify information. As a small boy I used index cards to make inventory of my father’s huge science fiction, fantasy and horror book collection — it’s probably hard to image my eight-year old self cherishing his hundreds and hundreds of cards in their filing cabinet. And that was Before Computers!

我一直對信息和信息分類工具充滿熱情。 作為一個小男孩，我用索引卡來記錄父親的巨大科幻小說，奇幻小說和恐怖書籍集–可能很難想象我八歲的自我珍惜在檔案柜中珍藏的數百張卡片。 那是在計算機之前！

My first computer was a then-modern Tandy TRS-80 model I. I’m a veteran of the ZX Spectrum vs. Commodore 64, the Atari ST vs. Amiga and the PC vs. Mac wars (and arguably chose the ’wrong’ side each time). I’ve done newspaper layouts using scissors and glue, then went on to PageMaker, from there to QuarkXPress and then to InDesign — and at each step I remember the same heated discussions about which tool really was the best.

我的第一臺計算機是當時的現代Tandy TRS-80型號I。我是ZX Spectrum與Commodore 64，Atari ST與Amiga以及PC與Mac戰爭的元老(并且可以說選擇了“錯誤”每次)。 我已經用剪刀和膠水完成了報紙的版面設計，然后去了PageMaker，從那兒到QuarkXPress，再到InDesign。在每一步中，我都記得關于哪種工具確實是最好的相同的激烈討論。

The difference is: there really was a huge difference between, say, QuarkXPress and InDesign and there was an objective reason to choose one tool over the other one. The tools were also incredibly expensive — I remember one memorable occasion when it was cheaper for my company to fly me to New York to buy a suite of software than it was to buy it in Belgium.

所不同的是：真有之間，也就是說，一個巨大的差異的QuarkXPress和InDesign并有一個客觀的理由選擇在其他一一工具。 這些工具也非常昂貴-我記得有一次令人難忘的場合，當時我公司飛往紐約購買一套軟件要比在比利時購買一套軟件便宜。

The World Wide Web changed all that.

萬維網改變了這一切。

I was spoon-fed on choose-your-own-adventure books and computer adventure games; I was making hypertext documents years before there was HTML. And the moment there was HTML, I started making websites. In 1994 I was making websites for a living and I haven’t stopped since, really. It’s sometimes hard not to feel like a dinosaur: I remember the first <img>, the first <table>, I remember realising the world had changed when I saw FutureSplash Animator in 1996 (which later became Flash), and I remember the same feeling when I saw the CSS Zen Garden in 2003 and Microsoft’s black magic with XMLHttpRequest, that Jesse James Garrett so perfectly framed when he coined Ajax.

我喜歡選擇自己的冒險書籍和計算機冒險游戲。 在沒有HTML的幾年前，我就制作了超文本文檔。 并有 HTML的那一刻，我開始做網站。 1994年，我制作網站為生，從那以后我一直沒有停止過。 有時候很難不感到自己像恐龍：我記得第一個<img>，第一個<table>，我記得當我在1996年看到FutureSplash Animator(后來變成Flash)時意識到世界已經改變了，我記得同樣當我看到2003年CSS Zen Garden和Microsoft的XMLHttpRequest的黑魔法時，Jesse James Garrett 創造了Ajax時就如此完美地構筑了這種感覺。

HTML was, above all else, the great equaliser. Before the recent-ish explosion of JavaScript frameworks where we suddenly got to single page websites that need to download half the internet to display a Hello world, there was view source.

HTML最重要的是均衡器。 在最近出現JavaScript框架爆炸之前，我們突然進入了單頁網站，需要下載一半的互聯網以顯示Hello世界，這里有view source 。

HTML is a very simple way to describe the structure and contents of a web page. Anyone could look at the source code for any web page, learn from it, and make their own. The tool didn’t matter: whether it was Notepad or Sausage Software’s HotDog, it remained no more than text, a couple of tags and some images. The playing field was completely level.

HTML是描述網頁結構和內容的非常簡單的方法。 任何人都可以查看任何網頁的源代碼，從中學習并創建自己的網站。 該工具并不重要：無論是記事本還是Sausage Software的HotDog，它僅保留了文本，幾個標簽和一些圖像。 比賽場地完全平整。

從開發人員到設計師 (From developer to designer)

I have done a lot of software development but I’ve never been a “real” developer.

我已經做了很多軟件開發，但是我從來都不是一個“真正的”開發人員。

I was involved in sales, worked with the client to decide what the thing should do, decided together with graphic designers what it should look like, and with developers how exactly it should work.

我參與了銷售，與客戶一起確定應該做什么，與平面設計師一起確定外觀，以及與開發人員一起確定應該如何工作。

We didn’t call it like that back then, but we always started from information architecture, then moved to conceptual design and then graphic design: not much has changed, really.

那時我們并沒有這樣稱呼，但是我們總是從信息架構開始，然后又轉向概念設計，然后轉向圖形設計：實際上并沒有太大的改變。

How we made the things and what tools we used: absolutely nobody ever cared. When we made an incredibly extensive website for Pioneer in the early 1990s, many pages were painstakingly hand-created, but other parts were dynamically composed on the server using FoxPro. We later moved to Allaire ColdFusion, and we generated many images that used to be made by hand with Photoshop. Still no one cared.

我們如何制造事物以及使用什么工具：絕對沒有人關心。 當我們在1990年代初期為Pioneer制作了一個非常龐大的網站時，許多頁面都是手工創建的，但是其他部分卻是使用FoxPro在服務器上動態組成的。 后來我們搬到Allaire ColdFusion，并生成了許多以前用Photoshop手工制作的圖像。 仍然沒人在意。

When we needed to communicate our designs to the client, depending on the situation, we showed an actual running web application, or static web pages that looked dynamic, or a dummy web site made in Photoshop, or even pages literally copy-pasted together user print-outs and glue.

當我們需要根據情況將設計傳達給客戶時，我們展示了一個實際運行的Web應用程序，或者看起來像是動態的靜態Web頁面，或者是用Photoshop創建的虛擬網站，甚至甚至是用戶真正粘貼到一起的頁面。打印輸出和膠水。

It didn’t matter one bit how we got to the design. The only thing that mattered was the result.

我們如何進行設計并不重要。 唯一重要的是結果。

That was a huge eye-opener. I used to have these epic discussions (WordPerfect vs. Word! Mac vs. PC!) but working with actual clients for actual money made me pretty pragmatic pretty quickly. And the older I get the more pragmatic I get: I just have no patience any more for discussions between editor A and B, for futzing with details when we should be concentrating on the big picture, or for endlessly looking for new tools for no good reason.

那真是大開眼界。 我曾經進行過這些史詩般的討論(WordPerfect與Word！Mac與PC！)，但是與實際客戶合作以獲取實際收入使我很快變得非常務實。 而且年齡越大，我越實用：我不再忍耐于編輯A和B之間的討論，在我們應該專注于全局時細化細節，或者無休止地尋找新工具。原因。

That is not to say that I’ll stick to whatever I’m using now: I’m constantly evaluating new things. But anything new is going to have to be substantially better to make me invest in switching. I also refuse to be defined by the tools I use: we should really be able to do the work we need to do with whatever tool is available, and if there’s no advanced tools available, there’s always pen and paper on the lo-fi end and HTML/CSS/Javascript on the hi-fi end.

這并不是說我會堅持使用我現在正在使用的任何東西：我正在不斷評估新事物。 但是，要使我投資于轉換，任何新事物都必須變得更好。 我也拒絕由使用的工具來定義：我們真的應該能夠使用任何可用的工具來完成我們需要做的工作，并且如果沒有可用的高級工具，那么在低保真音響方面總會有筆和紙以及HTML / CSS / Javascript(在Hi-Fi端)。

四種交付物 (Four types of deliverables)

I see four target audiences in my design work, and each has its own types of deliverables.

我在設計工作中看到四個目標受眾，每個目標受眾都有自己的交付物類型。

1. Myself: need to get my ideas down quickly and efficiently

   我自己 ：需要快速有效地將我的想法寫下來

2. Coworkers: need something tangible with just enough details that we can exchange ideas about it

   同事 ：需要有足夠細節的有形東西，以便我們就此交換意見

3. Client:

   客戶 ：

   in a

   在一個

   first phase, need something abstract enough that we don’t drown in detailed discussions but concrete enough to have a meaningful discussion about

   第一階段 ，需要足夠抽象的東西，以至于我們不會在詳細討論中淹沒，但足夠具體，可以就

   in a

   在一個

   second phase, need something close enough to the final product to get an approval for

   第二階段 ，需要足夠接近最終產品的東西才能獲得批準

4. Development team: need something clear and unambiguous, that can be the yardstick for the final product

   開發團隊 ：需要清晰明確的東西，可以作為最終產品的準繩

To avoid any misunderstandings, I’ll define some of those terms:

為了避免任何誤解，我將定義一些術語：

• Coworker: people I’m closely working together with on a design team. They’re not necessarily people at my company, Namahn: as a write this I’m working with a Namahn colleague on a design team consisting of subject matter experts and a product owner from the client, analysts from one subcontractor, visual designers from a second subcontractor and developers from a third subcontractor.

  同事 ：我正在與一個設計團隊緊密合作。 他們不一定是我所在的Namahn公司的人：寫這篇文章時，我正在與Namahn同事一起組成一個設計團隊，該團隊由主題專家和客戶的產品所有者，一個分包商的分析師，一個視覺設計人員組成。第二分包商和來自第三分包商的開發商。

• Client: decision makers at the client’s.

  客戶 ：客戶的決策者。

• Development team: on the one hand obviously software developers, but on the other hand often also the visual designers and/or front end team.

  開發團隊 ：一方面顯然是軟件開發人員，但另一方面經常是視覺設計師和/或前端團隊。

You may have noticed that I’m not talking about conceptual design, detailed design and graphical design. Most of the time our work does go through those stages of design, and they are certainly helpful to track where in the process we are, but to me they are almost orthogonal to the four target audiences and their types of deliverables.

您可能已經注意到，我不是在談論概念設計，詳細設計和圖形設計。 在大多數情況下，我們的工作確實會經歷設計的那些階段，它們無疑有助于跟蹤我們在流程中的位置，但對我而言，它們幾乎與四個目標受眾及其可交付成果的類型正交。

I’m typically working either alone, with coworkers, with clients or with developers, in iterations, at many different stages of a project and at many different levels of detail.

我通常是在項目的許多不同階段和許多不同的細節級別中，單獨地，與同事，與客戶或與開發人員一起進行迭代。

實踐中的工具 (Tools, in practice)

I do not think there’s one tool that can efficiently deal with all four types of deliverables.

我認為沒有一種工具可以有效處理所有四種交付物。

I’ll tell you what works best for me, but the last thing I want to do is to prescribe applications to anyone, because in general and for all deliverables it goes without saying that you should use what you feel you do you best work in. If you prefer working with Figma: not a problem! If Axure is your thing: great! If you feel most productive painting in Excel: you do you, Tatsuo!

我會告訴你什么最適合我的，但我想做的最后一件事，是規定的應用程序的人，因為在一般的和不用說，你應該用你覺得什么都交付你做你最好在工作如果您更喜歡使用Figma：這不是問題！ 如果您是Axure，那就太好了！ 如果您覺得Excel中的繪畫效果最好： Tatsuo，您愿意 ！

I do think it’s incredibly important to always keep costs and benefits in mind. As Voltaire said: Le mieux est l’ennemi du bien. Always weigh the cost of doing something the best way versus having it just good enough.

我確實認為始終牢記成本和收益非常重要。 就像伏爾泰說的那樣： Le mieux est l'ennemi du bien 。 總是權衡以最佳方式做某事的成本與擁有足夠好的本錢。

This sounds easier than it is, because you need to constantly evaluate whether your current ’quick and dirty’ solution isn’t weighing you down in the long run — and this becomes more important the longer-lived your deliverables are.

這聽起來比實際要容易，因為從長遠來看，您需要不斷評估您當前的“快速而骯臟”的解決方案是否不會使您感到沮喪—并且，隨著交付時間的延長，這一點變得越來越重要。

It’s pretty clear that if you’re doodling a possible concept you don’t need to keep a lot in mind. And it’s also pretty obvious that if just want to quickly show how items in a table might behave when resizing a window you don’t need to make the most perfect interactive prototype — a simple drawing might do the job, or at most some quick HTML. But when your table behaviour starts to get more complex and you need to show how it would work with different data, in different languages on different devices you don’t want to be making all possible variations in Photoshop.

很明顯，如果您要涂鴉一個可能的概念，則無需特別注意。 而且非常明顯的是，如果只想快速顯示表中的項目在調整窗口大小時的行為，則無需制作最完美的交互式原型-簡單的圖形就可以完成工作，或者最多可以使用一些快速HTML 。 但是，當您的表格行為開始變得更加復雜并且您需要顯示它如何處理不同的數據時，就需要在不同設備上以不同的語言使用不同的語言，那么您就不希望在Photoshop中進行所有可能的變化。

At some point you’ll have to move from away from “good enough”. At some point you’ll run into the limits of whatever tool you’re using and you’ll have to level up. (Sorry: there’s no hard and fast rules. It’s something you learn by doing, or by being told.)

在某些時候，您將不得不遠離“足夠好”。 在某些時候，您將遇到所用任何工具的限制，并且必須升級。 (對不起：沒有硬性規定。這是您通過做事或被告知學到的東西。)

On to the four types of deliverables!

討論四種交付物！

1.Swift了解想法-目標受眾：我自己 (1. Quickly get an idea down — target audience: myself)

The main aim is to reduce the distance between brain and page as much as possible.

主要目的是盡可能減少大腦和頁面之間的距離 。

I like pen and paper (more specifically, either Sharpies on A3 flip chart paper or a fine Uni-Ball Eye rollerball pen in a Leuchtturm1917 A5 dotted notebook). I also like whiteboards. If the whiteboard isn’t ruined beyond erasing and the whiteboard markers too dried out to see, that is.

我喜歡筆和紙(更具體地說，是A3掛圖紙上的Sharpies或Leuchtturm1917 A5虛線筆記本中的精美Uni-Ball Eye圓珠筆 )。 我也喜歡白板。 如果白板沒有被擦除而毀壞，并且白板筆太干而看不到，那就是。

But I prefer a digital whiteboard (either OneNote or Microsoft Whiteboard). I’ve been using a Microsoft Surface with a stylus for the last seven years, and it’s a game changer. A digital whiteboard is as free as a real whiteboard, except that it stretches out into infinity, you can zoom in or out, there’s an undo, you can move, copy, enlarge or reduce things. You could do the same in a more complex application like Adobe Illustrator, but I prefer there to be as little technology in the way: the less interface the better.

但是我更喜歡數字白板(OneNote或Microsoft白板)。 在過去的七年中，我一直在使用帶有觸控筆的Microsoft Surface，它可以改變游戲規則。 數字白板和真正的白板一樣免費，除了它可以延伸到無窮大，可以放大或縮小，可以撤消，可以移動，復制，放大或縮小事物。 您可以在更復雜的應用程序(如Adobe Illustrator)中執行相同的操作，但我更喜歡采用較少的技術：界面越少越好。

That being said: sometimes exploring ideas works better when there’s more rigidity. When I’m mainly going to be moving boxes around or working with highly repetitive content I tend to use Axure RP. Its repeaters allow me to dump a spreadsheet and immediately get repeated content, and that alone is worth it for me.

話雖這么說：有時，在更具剛性的情況下探索想法會更好。 當我主要是要移動箱子或處理重復性很強的內容時，我傾向于使用Axure RP。 它的中繼器允許我轉儲電子表格并立即獲得重復的內容，這對我來說是值得的。

And when I’m mainly dealing with text, as in an outline or meeting notes or writing an article, I use org mode in Emacs. Org mode is 17 years old and Emacs was initially released in 1976 so it’s definitely not for the faint at heart, but when you get into it, it’s absolutely a life-changing thing.

當我主要處理文本時，例如在大綱，會議筆記或撰寫文章中，我在Emacs中使用組織模式 。 Org模式已有17年歷史了，Emacs最初于1976年發布，因此絕對不是因為膽小的人，但是當您進入該模式時，絕對是改變生活的事情。

2.合作-目標受眾：同事 (2. Collaboration — target audience: coworkers)

The main aim here is to make it easy to efficiently collaborate to get to the bottom of a design issue, so it’s probably a good idea to all use the same tool.

此處的主要目的是使輕松有效地協作以解決設計問題的根源變得容易，因此所有人都使用相同的工具可能是一個好主意。

For early-stage ideas I prefer a digital whiteboard, for all the reasons mentioned above.

對于早期想法，出于上述所有原因，我更喜歡使用數字白板。

When we’re working on something more technical (e.g. with a lot of real data), when we’re refining an existing design or when more detail is absolutely necessary we use one of two strategies.

當我們在研究更具技術性的內容時(例如，使用大量真實數據)，在完善現有設計時或在絕對需要更多細節時，我們使用兩種策略之一。

Most of the time we get by with Axure. Again, I’m not at all saying this is the best tool there is — it’s just that in the projects I am currently working on we’ve all agreed to use it and it does the job for us: there’s that very useful repeater feature, decent templating, and I appreciate the way I can easily get simple interactivity (with interactions and dynamic panels) without having to jump through hoops or resorting to code.

大多數時候，我們與Axure相處得很好。 再說一次，我并不是說這是最好的工具–只是在我目前正在研究的項目中，我們都同意使用它，并且對我們有用：有一個非常有用的轉發器功能，體面的模板，而且我很欣賞可以輕松獲得簡單的交互性(具有交互性和動態面板)的方式，而不必跳過籃球或求助于代碼。

However: when only actual, dynamic, real data and actual real interaction can move us forward we will make a prototype in code. This could be anything from static HTML and CSS to a simple React application using real or mocked data; the important thing is that this is not meant to be production code at all. Its only reason to exist is to conceptualise or visualise a possible solution, so again: unless it makes things easier for you, quick and dirty is enough.

但是：當只有實際的，動態的，真實的數據和實際的真實交互才能使我們前進時，我們將在代碼中創建原型。 從靜態HTML和CSS到使用實際或模擬數據的簡單React應用程序，它都可以是任何東西； 重要的是，這并不意味著要生產代碼在所有 。 存在的唯一原因是將可能的解決方案概念化或可視化，因此再次重申：除非它使您更輕松，否則快速而骯臟就足夠了。

3.取得成功-目標受眾：客戶 (3. Get an OK — target audience: client)

This is the first type of deliverable the client (in the sense of “the decision makers at the client”) gets to see. Its main aim is to present the work you’ve done so far as well as possible and to get additional input and/or approval.

這是客戶看到的第一種交付物(在“客戶的決策者”的意義上)。 其主要目的是盡可能地介紹您已經完成的工作，并獲得更多的投入和/或批準 。

If we’re going to work together on different parts of the same project I’d use something that allows us to do that easily. Figma is an obvious choice here, in that it allows people to actually work together at the same time on the same content, but unless we’re really talking about rote work I personally prefer to physically design together, with one person drawing and two people thinking. It may sound like wasting valuable time to have two people doing the same work, but in my experience this kind of “pair designing” cuts time more than in half and vastly improves the quality of the result. It has the added benefit that you can use tools that have much more basic versioning, or that aren’t really made to work for multiple people to work on the same files.

如果我們要在同一個項目的不同部分上一起工作，我會使用一些可以使我們輕松實現的功能。 Figma在這里是一個明顯的選擇，因為它允許人們在同一時間在同一內容上實際一起工作，但是除非我們真的在談論死記硬背的工作，否則我個人更喜歡在物理上一起設計，一個人畫兩個人思維。 聽起來好像是浪費了兩個人來做同一工作的寶貴時間，但是以我的經驗，這種“ 成對設計 ”將時間減少了一半以上，并極大地提高了結果的質量。 它的另一個好處是，您可以使用具有更多基本版本控制功能的工具，或者不能真正讓多個人使用相同文件的工具。

This type of deliverable should not be given to a client without context. Do not send your design to the client without explanation and expect them to give any meaningful feedback. As a general rule I would absolutely recommend to show your work in a presentation. There’s a long article (or even book) to be written on the topic, but I find the most important thing to keep in mind is why you’re making the presentation and who you’re showing it to. In short:

沒有上下文，不應將這種可交付結果提供給客戶。 不要在沒有解釋的情況下將設計發送給客戶，并期望他們提供任何有意義的反饋。 通常，我絕對建議在演示文稿中展示您的作品。 關于該主題有很長的文章(甚至是書)要寫，但是我發現最重要的是要記住為什么要進行演示以及向誰演示。 簡而言之：

• The basics of your presentation should never be improvised: always know exactly what you’re going to say. Rehearse it until it sounds natural and improvised.

  演示的基礎知識絕對不能即興發揮：始終準確地知道您要說的是什么。 排練直到聽起來自然且即興。

• Be very clear about what you’re asking: input, approval, yes/no, scope decisions, priorities, …
  非常清楚您的要求：輸入，批準，是/否，范圍決定，優先級，…
• Know your audience: some clients may react very badly to black and white wireframes, while others understand better what is meant by that level of abstraction. In any case I try to avoid fake placeholder data at all times: either I do not show any data at all and replace any content with grey boxes, or I show data that is as real as possible.
  了解您的聽眾：有些客戶對黑白線框的React可能很差，而另一些客戶則更好地理解了這種抽象水平的含義。 無論如何，我總是嘗試避免使用偽造的占位符數據：要么我根本不顯示任何數據，而是用灰色框替換任何內容，要么顯示盡可能真實的數據。
• Time box and scope your presentation. People will inevitably meander away from the topic at hand, but try to keep on track as much as possible.
  時間框和范圍演示文稿。 人們不可避免地會彎腰手頭的話題，但要盡量保持步調一致。
• Record the presentation or (have someone) make detailed notes. Ideally you’ll be writing the meeting report yourself.
  記錄演示文稿或(請他人)做詳細記錄。 理想情況下，您將自己編寫會議報告。

It may sound old-fashioned to talk about presentations and PowerPoint (or Google Slides, or Keynote) when so many tools have great ways to show and share your designs. Yes, you could go over a design proposal in Figma or Adobe XD or Zeplin. You could send the client a URL and go through the file together.

當這么多的工具具有展示和共享設計的好方法時，談論演示文稿和PowerPoint(或Google幻燈片或Keynote)可能聽起來有些過時。 是的，您可以查看Figma或Adobe XD或Zeplin中的設計建議。 您可以向客戶端發送URL并一起瀏覽文件。

But I want the client to spend as much time and attention as possible on the design and as little as possible on any other distractions. When given the choice between showing my design proposal on an otherwise blank slide or using some other interface, even one as simple as a web browser, I will always choose the first option. I want the distance between the design and the client’s brain to be as short and unencumbered as possible. I also want to direct their attention where I want it to be, and physically not showing anything else except what I want them to think about is the best way to do that.

但是我希望客戶在設計上花費盡可能多的時間和精力，而在其他任何干擾方面則花費盡可能少的時間。 如果可以選擇在其他空白幻燈片上顯示我的設計建議，還是使用其他界面(甚至是像Web瀏覽器一樣簡單的界面)之間進行選擇，則我將始終選擇第一個選項。 我希望設計與客戶的大腦之間的距離盡可能短且不受阻礙。 我也想將他們的注意力轉移到我想要的地方，并且除了我希望他們思考的是實現此目的的最佳方法外，身體上什么也不會顯示。

If issues come up during the presentation (either of the “I hate it!” or the more useful “What if we did this…” variety) it’s up to you how to react. Don’t be afraid to say “I don’t know (yet)” or to say there’s no time to go into suggestions. Try to avoid getting bogged down in discussions that go outside the scope of the meeting — but if the opportunity presents itself, if there’s room for it and if you feel up to it: do take the opportunity for some on-the-spot co-design.

如果在演示過程中出現問題(無論是“我討厭它！”還是更有用的“如果我們這樣做……”變體)，則取決于您如何做出React。 不要害怕說“我還不知道”，或者說沒有時間提出建議。 盡量避免在討論的是去開會的范圍之內陷入困境-但如果機會出現， 在有空間的它， 如果你覺得到它： 不要趁機對一些在現場共設計。

As for tools in that kind of situation: we’re sort of back in the previous deliverable, where efficiency and communication are key. If you’re in a physical meeting a whiteboard or flipchart is ideal; if you feel like using a computer, make sure you’re so comfortable with whatever you’re going to use that you’re not going to choke, even with the added pressure of an (important) audience watching your every move. (I’ve done more than one impromptu design with nothing more than Excel, just saying.)

至于在這種情況下的工具：我們在以前的交付產品中有點倒退，而效率和溝通是關鍵。 如果您是在開會時，白板或活動掛圖是理想的選擇。 如果你喜歡用電腦，確保你與任何你要使用你不會嗆，即使有一個(重要的)觀眾在看你的一舉一動的壓力也很舒服。 (我只說了一點，即完成了不止一個即席設計，也沒有Excel。)

4.規范-目標受眾：發展 (4. Specification — target audience: development)

When you hand over your design to developers, the main aim is to let developers do what they do best and not to make them second-guess you.

當您將設計移交給開發人員時，主要目的是讓開發人員做他們最擅長的事情，而不是讓他們對您一視同仁 。

There are of course many different types of developers. At best you’ll be working with people that have an affinity for design and that think about solutions together with you. At worst you’ll have to hand over a design to a developer with little experience or with perhaps only back-end Java development experience, who can’t really be bothered to think about actual end users.

當然，有許多不同類型的開發人員。 充其量您將與對設計有濃厚興趣并與您一起考慮解決方案的人們一起工作。 最壞的情況是，您必須將設計移交給經驗不足或僅具有后端Java開發經驗的開發人員，而他們實際上并不需要考慮實際的最終用戶。

At best, developers are your best partners; at worst, they can be your worst nightmare.

充其量，開發人員是您最好的合作伙伴； 在最壞的情況下，它們可能是您最糟糕的噩夢。

If you’re in a longer-term project where development and design happen in parallel, you need to find a modus vivendi with the developers. Perhaps it’s because I’ve been on the development end of things, but I absolutely hate it when I see designers that make developers feel like they’re just there to blindly implement Whatever The Designer Has Designed And Now Deigns To Hand Down From On High.

如果您在長期的項目中同時進行開發和設計，則需要與開發人員一起尋找一種可行的方法。 也許是因為我一直從事開發工作，但是當我看到使開發人員覺得他們只是盲目地實施設計師設計的東西而現在打算從高處傳下來的設計師時，我絕對討厭它。 。

Developers are not at our service, just as we are not at their service: the both of us are at the service of whatever we’re making. Ideally we trust each other and realise we’re both involved in creative and necessary work, just in different ways.

開發人員不為我們服務，就像我們不為他們服務：我們倆都為我們所做的一切服務。 理想情況下，我們彼此信任，并意識到我們都以不同的方式參與了創造性和必要的工作。

Where possible, participate in developer rituals (e.g. stand-ups or other periodic meetings) and use the tools they use (e.g. don’t force them to look for information in a long unwieldy design document if all their other input is chunked in Jira/Confluence). Avoid potential blocking issues by involving developers early enough: it’s very common that what seems hard to you isn’t necessarily and what seems easy to you isn’t necessarily either. Be flexible and realistic: almost nothing is ever completely impossible, but realistically the costs may outweigh the benefits. This is where trust comes in: you need to be able to trust the developer who tells you something is very difficult, just as the developer needs to be able to trust you when you say you absolutely need something.

在可能的情況下，參加開發人員的儀式(例如站立會議或其他定期會議)，并使用他們使用的工具(例如，如果其他所有輸入都在Jira /合流)。 通過盡早讓開發人員參與來避免潛在的阻塞問題：通常情況下，您認為困難的事情不一定不一定，而對您看來容易的事情也不一定。 靈活而現實：幾乎沒有什么是完全不可能的，但實際上成本可能超過收益。 這就是信任的來源：您需要能夠信任告訴您某件事的開發人員非常困難，就像開發人員需要在您絕對需要某些東西時信任您一樣。

The absolute ideal is that you’re able to create and maintain a design system — a living system that contains everything necessary to create applications, from the general design principles down to the detailed specifications of screens and individual components.

絕對理想的是，您能夠創建和維護設計系統 -一個活潑的系統，其中包含創建應用程序所需的一切，從一般的設計原理到屏幕和各個組件的詳細規格。

Realistically, you’re often working on a screen by screen or component by component basis, and it’s up to you as a designer to keep the bigger picture in your head.

實際上，您經常在逐個屏幕或逐個組件的基礎上進行工作，而作為設計師，則取決于您如何掌握更大的畫面。

Whether you’re in a long-term iterative process with development or if your project ends with a single handover to a development team, you need to be as clear and as unambiguous as possible in your deliverables. Depending on the design maturity of the developers that could mean anything from simple annotated drawings to a full-blown formal specification with functional and non-functional requirements and detailed guidelines for typography, colour, interaction, screens, components, …

無論您是處于開發的長期迭代過程中，還是您的項目以一次移交給開發團隊的結果結束，您都需要在交付物中盡可能保持清晰和明確。 取決于開發人員的設計成熟度，這可能意味著從簡單的帶注釋的圖紙到具有功能和非功能要求的成熟正式規范以及有關版式，顏色，交互作用，屏幕，組件等的詳細準則，等等。

可重復使用的設計資產庫？ (A library of reusable design assets?)

There’s a time and a place for UX design component libraries.

UX設計組件庫有一個時間和地點。

On the one hand: nobody likes to reinvent the wheel, and there’s little worse than having to manually change many dozens of screens because some small details common to all those screens have changed. On the other hand: in early iterations of a design we’re realistically just dealing with boxes and the occasional checkbox, radio button or arrow. Is it really worth it to make a component library for conceptual designs or wireframes?

一方面：沒有人喜歡重新發明輪子，而且與手動更改許多屏幕相比，沒有什么比這更糟糕的了，因為所有這些屏幕共有的一些小細節都已更改。 另一方面：在設計的早期迭代中，實際上，我們只是處理框以及偶爾的復選框，單選按鈕或箭頭。 為概念設計或線框制作組件庫真的值得嗎？

It can be very useful to to leverage templates and components in your tool of choice, e.g. to avoid manually copy-pasting navigation on all your pages or to quickly build up table or grid layouts, but I would argue it’s very, very seldom a good investment to spend time making a wireframing library of headings, forms, navigation, lists etc. for this kind of simple or more informal deliverables.

它可以向您所選擇的工具，如利用模板和組件是非常有用的，以避免手動復制粘貼的所有網頁或快速構建表或網格布局的導航，但我認為這是非常非常難得的好花時間為這種簡單或更非正式的交付物制作標題，表單，導航，列表等的線框圖庫。

An actual library with standard fonts, colours and components does make absolute sense when standardisation and consistency are important, i.e. when you’re designing many different screens, when there’s more than one designer involved, and when you’re creating deliverables for client approval or for development.

當標準化和一致性很重要時，即具有標準字體，顏色和組件的實際庫確實具有絕對意義，例如，當您設計許多不同的屏幕時，涉及多個設計師時以及在創建可交付成果以供客戶批準或為發展。

But then we’re most probably not talking about early conceptual designs or wireframes any more, and whatever library you’re going to make is going to client- or project-specific.

但是，我們很可能不再談論早期的概念設計或線框了，無論您要制作的庫是針對特定于客戶或項目的。

The most important criterium for choosing any tool is how well it fits the purpose: does it help you to quickly set down concepts and ideas? Does it help you to efficiently communicate within your team, with decision-makers and with developers?

選擇任何工具的最重要標準是工具與目的的適應性：它是否可以幫助您快速確定概念和想法？ 它是否有助于您在團隊內部，與決策者和開發人員之間進行有效溝通？

It’s a poor workman who blames his tools, and in design the medium is not the message. Good design can be communicated well using very basic tools.

指責他的工具的是一個可憐的工人，在設計中，信息不是信息。 使用非常基本的工具可以很好地傳達良好的設計。

Always keep your eyes peeled for new tools. Get to know them, make a small personal test project with anything that looks interesting to get a real feel for them. But don’t jump ship to something new unless there’s an absolutely compelling reason to do so, no matter how tempting it may seem.

始終睜大眼睛尋找新工具。 認識他們，做一個小的個人測試項目，用看起來有趣的東西讓他們真正感受到。 但是，除非有絕對誘人的理由，否則不要跳槽到新的事物上，無論它看起來多么誘人。

Nobody cares how the sausage is made, as long as it’s a good sausage. Spend your time making good sausages, not looking for slightly better sausage machines. And know when you need to make an actual sausage, and when a picture of a good-looking sausage or even an ingredient list is enough.

只要是好香腸，沒人會在意香腸的制作方法。 花時間去制作優質的香腸，而不是尋找更好的香腸機。 并且知道何時需要制作實際的香腸，何時需要漂亮的香腸甚至什至是配料表的圖片。

I’m a designer at Namahn in Brussels, Belgium. Find out more about us on the information superhighway, on instagram, the twitters or even TheFacebook.

我是比利時布魯塞爾Namahn的設計師。 了解更多有關我們 在信息高速公路 上 的Instagram ， 在嘰嘰喳喳 甚至 TheFacebook 。