For over 2 years at a young product company, I collaborated with talented engineering folks for a 0 → 1 suite of products. Here are my learnings and key takeaways. Of course, these are my views and do not represent those of my employers or colleagues.

在一家年輕的產品公司工作了2年多，我與才華橫溢的工程人員合作，開發了0→1套產品。 這是我的經驗和主要收獲。 當然，這些只是我的觀點，并不代表我的雇主或同事的觀點。

1.沒有溝通過度的事情。 (1. There is no such thing as over-communication.)

Every early stage startup teammate is a critical cog in building the future together. And teams get stuck when:

每個早期創業團隊成員都是共同構建未來的關鍵。 在以下情況下，團隊會陷入困境：

• There’s no shared understanding of what’s being built. Solve this with running async documentation available for everyone.
  對所構建的內容沒有共識。 通過運行適用于所有人的異步文檔來解決此問題。
• Miscommunication among teammates (This happens more often than you’d imagine!). Solve this with scheduling regular catchups with your collaborators.
  隊友之間的溝通不暢(這種情況經常發生，超出您的想象！)。 通過與合作者安排定期的趕超來解決此問題。

Embrace the culture of over-communication. Communicate your design rationale, your assumptions and expected outcomes.

擁抱過度交流的文化。 傳達您的設計原理，假設和預期結果。

• Own it. Talk about it. Write about it.
  擁有它。 說說它。 寫吧。
• Ask questions. Ask for data to validate your assumptions.
  問問題。 要求數據以驗證您的假設。
• Set yourself up for success. Set your work up for success. (It helps to define design success from your teammates’ perspective as well.)
  為成功做好準備。 為成功做好準備。 (它也有助于從隊友的角度定義設計成功。)

2.設計與像素完善和移交同樣重要。 (2. Design is as much about alignment and enabling as it is about pixel perfection and handover.)

• Keep all teammates in the loop.
  讓所有隊友保持聯系。
• Use storytelling frameworks if necessary.
  如有必要，使用敘事框架。
• Take them through the journey map and user story.
  帶他們瀏覽旅程地圖和用戶故事。
• Invoke the name of your persona if you really need to.
  如果確實需要，請調用角色的名稱。

Understand that everybody communicates uniquely. Some collaborators are spontaneous, and immediately give you crucial points of feedback . Some are deliberate, they think through the solutions — and will tell you a potential snag or two later in the week. Know how to communicate with each of them, tune your ears, listen to their input.

了解每個人的溝通方式都是獨一無二的。 一些合作者是自發的，并立即為您提供重要的反饋意見。 他們會仔細考慮一些解決方案，并會在一周中晚些時候告訴您一兩次潛在的困擾。 知道如何與他們每個人溝通，調音，聆聽他們的意見。

Engineers can contribute to the design process greatly by bringing the constraints to your notice. Most times, these constraints come in after they have put in some energy into the solution-forming exercise. As you get better at enabling conversations, snags will be noticed earlier and dealt with faster.

工程師可以通過將約束告知您來為設計過程做出巨大貢獻。 大多數情況下，這些約束是在為解決方案形成工作投入了一些精力之后才出現的。 隨著您更好地進行對話，障礙會更早被發現并更快地得到處理。

The better aligned the engineer, the more points-of-failure identified before writing the code. The better the designer, the more concrete the design solution becomes with user actions and relevant usage data.

工程師的協調性越好，編寫代碼之前確定的故障點就越多。 設計者越好，設計方案就越能根據用戶的操作和相關的使用數據而變得更加具體。

3.一起尋找解決方案的穩定性。 (3. Look for robustness of the solution, together.)

We designers feel good when we have our assumptions proved right. We ask questions within the organisation and feel validated. Validation makes you feel good about being right about your design. It makes you tightly coupled with your solutions. Look for better return on effort instead. Ship as many production pixels as you can. Write as many connecting documents as you can. Setup systems for your team’s success, because design is (and will remain)a collective cross functional effort.

當我們的假設被證明正確時，我們的設計師會感覺良好。 我們在組織內提出問題，并得到驗證。 驗證使您對設計正確感到滿意。 它使您與解決方案緊密結合。 尋找更好的努力回報。 可以運送盡可能多的生產像素。 盡可能多地寫入連接文檔。 為團隊的成功建立設置系統，因為設計是(并將保持)跨部門的共同努力。

Someday when the design falls through, (and it will), a lesser enabled design culture will lead to teams pointing fingers at one another. Build a robust connected design culture and better problem-solving conversations will follow, automatically.

某天，當設計失敗時(并且將會)，一種啟用程度較低的設計文化將導致團隊相互指責。 建立強大的連接設計文化，隨后將自動進行更好的解決問題的對話。

4.重點是實驗性的，也是漸進的。 (4. The point is to be experimental, but also incremental.)

In a small startup crunched for time, space and energy, every different-looking pixel cluster translates to work. Work that needs to be done by the engineers. And if the layout looks even slightly too different from the one existing at the moment, it becomes tough to get the team to agree to the proposed direction.

在一家時間，空間和能源緊張的小型初創企業中，每個看起來不同的像素簇都可以正常工作。 工程師需要完成的工作。 而且，如果布局看起來與目前的布局甚至略有不同，那么很難讓團隊同意提議的方向。

Sometimes, it takes time to ring in the concept of ‘exploration’, especially in a tech-heavy company; without overwhelming your engineering teammates. Make sure you invest time in making them comfortable with not implementing before you show them a design direction coming their way.

有時，需要花一些時間來敲定“探索”的概念，尤其是在技術含量高的公司中。 而不會壓倒您的工程團隊成員。 在向他們展示他們的設計方向之前，請確保您花費時間使他們對不習慣實施感到滿意。

One of the ways to deal with this is to have a “Sandbox” version that you work on when a feature is experimental. Once the direction is set, the polished version can be merged with the main set of production screens. Don’t show the kitchen sink unless you really have to. Present your ideas well, don’t present your idea well.

解決此問題的方法之一是擁有一個“沙盒”版本，當功能處于試驗階段時您可以使用該版本。 設置方向后，可以將拋光版本與主生產屏幕合并。 除非確實需要，否則不要顯示廚房水槽。 很好地表達您的想法，不要很好地表達您的想法。

5.大圖有時可能只是大圖的一小部分。 (5. The big picture can sometimes be a small part of a bigger picture.)

Don’t assume you know everything. You don’t. And most times, it’s the best thing that can happen to you.

不要以為你什么都知道。 你不知道 在大多數情況下，這是可能發生在您身上的最好的事情。

Even in the presence of data, positive feedback, videos full of nodding and smiling users — be on the lookout for places of improvement or short sightedness. The best solutions are simple. That’s because the best solutions don’t ask the users to jump through multiple hoops to solve their problem.

即使存在數據，積極的反饋，充滿點頭和微笑的用戶的視頻—仍在尋找改進的地方或短視的地方。 最好的解決方案很簡單。 這是因為最好的解決方案不會要求用戶跳過多個障礙來解決他們的問題。

Most users, will take whatever decent offering you provide and highly proclaim your product. This is true, especially for 0 to 1 products where you have early mover advantage.

大多數用戶都會接受您提供的任何體面的產品，并高度評價您的產品。 的確如此，尤其是對于擁有先發優勢的0比1產品。

But remember, the user seldom sees the full picture. And it helps to keep the complex inner workings of the product away from them.

但是請記住，用戶很少看到完整圖片。 而且它有助于使產品的復雜內部運作遠離它們。

As a designer you are in charge of providing context for each of these challenges and define boundaries.

作為設計師，您負責為每一個挑戰提供背景并定義邊界。

• Don’t let Dribbble fool you into thinking interfaces are always mess-free.
  不要讓Dribbble欺騙您，以為界面始終沒有混亂。
• Don’t let the stories of design podcast guests confuse you into thinking that the paths to success are linear and easy.
  不要讓設計播客的故事迷惑您，使您認為成功之路既線性又輕松。
• Don’t let anybody tell you what you can or cannot think about.
  不要讓任何人告訴您您可以考慮或無法考慮的事情。
• Don’t let anybody stop you from being a storyteller of the product you build.
  不要讓任何人阻止您成為您所制造產品的講故事的人。

The real world is a dirty place with

現實世界是一個骯臟的地方

• Incomplete inputs

  輸入不完整

• Unreasonable expectations

  期望不合理

• Unexpected changes based on

  意外的變化基于

• Unfounded aspirations

  毫無根據的愿望

Seek to work on any one of these challenges at their respective stages of the process. Pick the battles you can win, without making them look like battles.

尋求在流程的各個階段應對這些挑戰中的任何一項 。 選擇您可以贏得的戰斗，而無需使其看起來像戰斗。

Ask for all the tools, words, code snippets you need to make the end user happy. Get things done. And yes, you will screw up. Early stage startups are not for the faint hearted. When you are wrong, everything can go wrong.

詢問使最終用戶滿意所需的所有工具，單詞，代碼段。 把事情做完。 是的，您會搞砸。 早期創業公司不適合膽小者。 如果您做錯了，一切都會出錯。

If you are right but the business assumptions are wrong, you still will be redoing the whole thing again. And you will go through “FFS_finalV9” version cycle again. You get to do the “I told you so” smirk only for a few hours.

如果您是正確的，但是業務假設是錯誤的，那么您仍然會重新做一遍整個事情。 您將再次經歷“ FFS_finalV9”版本周期。 您只能做幾個小時的“我告訴過您”的傻笑。

Lastly, it’s easy to be bogged down by the unstructured inputs presented to you with “change the world” hubris. But you will get through it. You are empathetic enough to see it through. I believe in you. Go now, and do good work.

最后，很容易被“改變世界”的傲慢呈現給您的非結構化輸入所困擾。 但是您會成功解決的。 您有足夠的同理心去看透它。 我相信你。 現在去，做好工作。

Thank you for reading this article! Shoutouts to RAHUL DAS, Aishwarya Naik and Nikhil Jois for reviewing the content. ?🏽

感謝您閱讀本文！ 向RAHUL DAS ， Aishwarya Naik和Nikhil Jois致謝，以審核內容。 ?🏽

I design digital products and conduct conferences in India. Reach me on Twitter @anirudhux. Feel free to go through my portfolio on www.anirudhux.com.?🏽

我設計數字產品并在印度舉行會議。 通過Twitter @anirudhux與我聯系。 隨時瀏覽www.anirudhux.com上的我的投資組合。?🏽