profile

Soking

Soking 來信:軟體小白如何觀察並認識軟體開發?

Published about 1 year ago • 1 min read

不論是在產品設計工作上遇到的利害關係人,或是 UX 教學上遇到的轉職者,我都會遇到相當比例是從未參與過軟體開發的人。

這是一件好消息,代表軟體走向大眾化,每個人的工作都有機會涉及到軟體的規劃。

這是一個壞消息,溝通的門檻是阻礙,軟體開發的溝通是一門既深且廣的領域,即使是專業人員也不敢說自己能夠涉及方方面面,對於零經驗的人來說更可怕,可能對方講的每個字你都認識,但組合在一起變成不像人話。

我很喜歡羅蘋荷布在奇幻小說《刺客學徒》中,讓老刺客說的一句話:「要入一行,必先學會行話。」

如果說我要列出三個最基礎要認識的軟體開發觀念,應該會是:

  • 軟體的用途是傳遞資訊
  • 觀察輸入與輸出的結果
  • 分辨功能與資訊內容

▋軟體的用途是傳遞資訊 ▋

雖然聽起來很像是廢話,但軟體是用來傳遞資訊的,這邊講的資訊表現形式有:文字符號、圖像、聲音。

傳遞資訊具體來說是執行三件事情,那就是:儲存、運算、顯示。

如果你有興趣,可以 google 一些專有名詞,例如「ASCII編碼」、「Unicode」,電腦其實不知道人類輸入的東西是什麼,如果每台電腦要互相溝通,那就需要一個統一的規則,讓我在 A 電腦上輸入的資訊,傳遞到你的電腦上也可以顯示相同的東西。

舉例來說,我們很習慣使用的 emoji 符號,背後就是使用 Unicode 的編碼表,但你會發現同樣的表情符號,在 Apple 的 iPhone 手機上與網頁上會顯示不同的相似圖案,甚至偶爾你會看到一些名為「tofu」的小正方形方塊 (☐),這就是你所使用的軟體或 emoji 符號尚未被支援。

到這邊我們可以了解,建立並共同遵循基本的規則,軟體才能互相溝通。

這個基礎觀念影響甚廣,可以解釋非常多軟體開發現場的困難,例如 Wordpress 為什麼號稱萬能,但實際上很難用?

Wordpress 號稱的萬能源自於開放性,任何會寫軟體的人都可以自行發佈插件程式,讓你安裝到自己的 Wordpress 上。

你還記得上面提到的基礎觀念嗎?建立並共同遵循基本的規則,軟體才能互相溝通。

那麼全世界成千上萬個寫了 Wordpress 插件程式的人,他們的軟體之間會一起制定什麼基本規則嗎?答案當然是沒有,他們只遵循了最低限度符合 Wordpress 的規範,結果就像 IKEA 的組合家具沒辦法跟 B&Q 買的組合家具連接在一起,但都能放進你的房間。

許多公司的數位轉型也面臨一樣的窘境,以致於全公司的資訊是碎片化的存在於各個不同的會計軟體、Excel 文件、SaaS 服務、內容管理系統、ERP、廣告後台之中。

用於傳遞資訊的軟體,因為每一種資訊各自使用不同的方式產生,並且各自處於封閉的軟體之中,成為現代工作者耗費最多心力進行整合的工作,可以說是軟體之間的溝通困難,創造了許多辦公室文書工作。

在個人的層級可能只是略微不便,例如我有記帳習慣,在便利商店買東西的過程,就要掏出手機載具條碼、數位支付 APP 以及記帳 APP,切換三個不同的服務。

到了大型企業的層級,已經幾乎沒有人可以搞懂整體公司的資訊之間互為因果的流向了。

▋觀察輸入與輸出的結果 ▋

幫助人類理解以及正確執行符合軟體設計目的的輸入與輸出,正是 UX 從業者的主要戰場。

前面提到,傳遞資訊具體來說是執行儲存、運算、顯示。

如何讓人類理解機器與電腦裝置所需的輸入訊息規則?裝置是否正確收到所輸入的訊息?裝置收到訊息之後處於什麼樣的處理狀態?會如何返回人類預期的輸出成果?

自從人類開始探索自身與機器裝置之間的關係之後,這一系列的問題發展出了人機互動的專業學科,隨著軟體的普及化,過去只有受過訓練的專家才懂得如何與機器與電腦裝置打交道,此時社會上只有少數人受過訓練知道如何操作軟體,當時的軟體設計是服務於商業目的或技術上的可行性,因此多半聚焦在商業邏輯或技術流程。

曾經光是「打字輸入」就是一門經過訓練後可以謀生的電腦操作技能。

現在大多數的生活事務都逐漸涉及到了人與機器互動的議題,當認知心理學進入軟體設計的領域後,提出「人類的大腦有認知偏誤的天生缺陷,因此設計應該避免人類犯錯」之後,軟體開發的領域才逐漸理解,要讓軟體普及化發揮影響力,就必須觀察與理解人類的使用情境,降低軟體操作的使用門檻。

你認為流暢好用的現代軟體,都是刻意針對「系統一」所設計的,透過介面上的預告、暗示、行為引導、防呆設計,讓你不用耗費太多心力就可以輕鬆達成開啟軟體的操作目的。

而「資訊的輸入」衍生出大量的軟硬體產品,大家發現過去資訊的輸入是想辦法從實體的類比世界進行轉換,例如掃描照片變成數位檔案,那為什麼不一開始就使用數位相機拍攝數位照片呢?

同樣的道理,工作現場的紀錄、製圖、測量、計算、監控、訊息公告、移動、支付、影音錄製、描繪著色,這些過去存在於實體世界產生資訊內容的行為,能不能在一開始就成為數位檔案?

解決了麻煩的輸入議題後,人類世界產生資訊的行為,逐漸變成原生的數位檔案為主,我們有了各種不同的欄位儲存資訊內容,用來識別代表實體世界資訊的事物。

GPS 的定位與遊戲圖像結合,讓人們可以走在路上捕捉數位遊戲中的寶可夢。 動作偵測、移動、生理資訊的感應裝置,讓戴在腕上的手錶提醒你坐太久了應該起來喝水散步。 手指點擊虛擬鍵盤輸入文字符號,觀察已讀、未讀以及多少人給了 emoji 表情,影響你的心情。

觀察人類如何跟機器與電腦裝置互動產生何種資訊,以及觀察人類如何辨認和理解機器與電腦裝置產生的訊息回饋,會是成為 UX 工作者之後的職業病。

▋分辨功能與資訊內容 ▋

如果以廚房來比喻,軟體的功能就像是菜刀或砧板等廚具,而資訊內容就像食材。

軟體在執行儲存、運算、顯示的過程中,就彷彿從洗菜籃中挑選食材出來切菜,炒菜調味之後裝盤放到你眼前。

給你一堆 GPS 座標以及時間戳記,你可能會覺得莫名其妙。

但是按照時間戳記的順序,將 GPS 座標串連起來,再搭配地圖繪製每個座標點的路徑節點,就成為你的跑步軌跡或者是行車記錄。

軟體裡面的功能是各種將資訊內容加工的方式,例如裁切照片、將文字輸入轉換成 emoji 圖案、判斷一則訊息該傳送給誰看、加總你購物車裡面的金額、驗證你輸入的信用卡號、根據你輸入的電話號碼撥打給指定對象、顯示文字與圖片在網頁上、根據你滑鼠的點擊顯示互動介面。

許多討論軟體需求的場合,在言語之間混搭了功能與資訊內容的需求,例如「幫我在這邊放一個圖表」,聽到這個描述的人其實什麼都沒有得到,這跟「今天中午幫忙買吃的」差不多空洞,既不知道要買給誰、什麼場合需要、吃什麼與不吃什麼、幾點需要,也不知道預算是多少。

如果追問不到細節,只聽到「問這麼多幹嘛?你是專業的你決定」,那只買了一份蚵仔麵線與臭豆腐,要給一群午餐會議的高階主管們吃,似乎也不是奇怪的結果。

偏偏在軟體開發現場的需求討論中,誰在什麼情境下、如何獲得資訊內容、應該怎麼處理訊息、在什麼情況下呈現,經常缺東缺西,很少有人獲得充分的資訊就被要求開始工作。

因此就會發生蓋好了五層樓的公寓後,被要求中間要挖空增加電梯,既然都要加電梯了,為什麼沒有停車位呢?五層樓好像不夠用,為什麼不能是二十層樓?

因為軟體是抽象的,所以憑空增加電梯的需求,聽起來跟在書房加裝一台冷氣差不多,這也是許多軟體從業人員面臨的溝通困難。

如何精準的分辨軟體開發中的功能與資訊內容需求,會是新手小白與資深熟手的分水嶺。

結語

總結來說,如果不論你是負責許願的需求方,或是剛踏入這個領域的人,希望本文討論的三個基礎的認知,能夠幫助你更好理解這個行業。

  • 軟體的用途是傳遞資訊,建立並共同遵循基本的規則,軟體才能互相溝通。
  • 觀察輸入與輸出的結果,幫助人類理解以及正確執行符合軟體設計目的。
  • 分辨功能與資訊內容,幫助你在軟體開發現場更精準的溝通。

by Soking

Soking

千綺創意設計 Co-Founder / 產品設計總監,目前經營軟體領域的體驗設計顧問公司,也從事 UX 教學,喜歡以工作坊形式,引導你體驗 UX 領域的專業知識。 工作聯絡:service@soking.cc

Read more from Soking

哈囉,朋友 你如何評估一件事情做得好呢? 直接聽聽顧客的聲音如何? ▋聽取顧客聲音,就要照單全收嗎? ▋ 我曾經在自己舉辦活動的時候,收到參加者的回饋,希望多聽一些實際案例。 太棒了,我下次就加碼加料,多講三十分鐘客戶案例的經驗談。 但是別的參加者抱怨了,他們說:只聽經驗談不知道該如何落地。 又有參加者問,這些東西該怎麼樣才能變成作品集? 如果我每聽見一種類型的聲音,就在活動裡面多添加一個元素,很快就會發現,原來的規劃變成了四不像。 更糟糕的是,明明是聽取顧客回饋作的調整,結果還讓大家都不滿意了。 難道聽取顧客意見不對嗎?該怎麼辦呢? 我們的確需要聽取顧客的聲音,但是不能只憑感覺。 一來,人都會有偏見,很容易只看見自己想看見的事情。 二來,所有的意見都照單全收,只會迷失自己。 那些顧客的聲音沒辦法讓我們知道怎麼樣才是對的。 我們需要的是相對客觀的蒐集顧客聲音的方式,並且能攤開來檢視證據,跟夥伴一起合理評估。 如果你已經有實際在運作的產品服務,但平常都是盯著廣告觸及以及訂單數量在檢討。 我想與你分享運用「滿意度問卷」來聆聽顧客聲音的方式。 ▋辨別客群的常用題型:人口特徵 ▋...

about 24 hours ago • 1 min read

哈囉,朋友 相信沒有人會反對越多顧客越好。 許多時候「閃電擴張」甚至被視為萬靈丹。 但很多時候不是擴張就可以解決一切商業問題。 如果我們把產品服務想像成開一台公車上路。 你可能會在沒有客群的地方開拓新路線,這是資源上的浪費。 你可能會在擴充車隊的時候發現沒有司機以及後勤保養不足,這是缺乏增長的條件。 你可能會想經營觀光路線,卻發現因為缺乏方便的外國人支付方式以及公車路線的 GPS 動態,外國客群沒辦法透過 Google Map 輕鬆方便的使用,導致願意嘗試的人很少。 若是要專門為觀光路線投資這些技術,其他一般路線又看不見效益。 這些「用戶增長」上會遇到的問題,都可以燒錢解決。 但我們的資源會在哪些事情上面燒掉呢? 以下我想列出幾個評估重點,用來與你一起思考用戶增長: 產品是否 PMF 現有目標客群的 LTV 獲客成本的結構 目標族群的增長環境 新羊群與第二隻羊 ▋產品服務是否 Product-Market Fit ▋ Product-Market Fit 是指,我們的產品是否有符合市場需求? 認真的說,有許多產品在沒有 PMF 的情況下,開始想著要放大。...

8 days ago • 1 min read

哈囉,朋友 我在與人討論 ABZ 計畫時,經常聽到一個困擾,類似這樣:「除了正職的工作以外,我假日再去兼差,一開始收入提昇了不少,但發現越來越沒有自己的休息時間。直到後來正職工作產生變動,連假日都要去支援,害我不能進行兼職工作,收入馬上變少,但又不能用兼職工作取代正職,感覺做了很多事情但沒有任何累積。」 像這樣明明很努力,但卻滿盤皆輸的局面,動輒以年為單位白白浪費我們的歲月年華。 問題到底發生在哪邊呢? 相信你應該可以察覺,在這樣的故事中,兼職工作本身並不具備當 A 計畫不可行的時候,隨時能夠以人生備案的姿態頂替上去的可行性。 以致於當 A 計畫變得更加消耗人生餘裕時,變成要捨棄兼職工作,於是人生選項減少,不僅僅是回到原點,狀況還更加糟糕。 在思考如何擴充人生選項的 ABZ 計畫框架中,有三個評估方向可以幫助我們檢視自己的計畫,是否具備未來可行性,我將這個概念稱為「最小單位的可行性」,包括: 可獨立執行 可明確交付 可轉移情境 ▋可獨立執行:每個計畫都是獨立的一人部門 ▋ 我們常常聽說過「一人公司」的概念,除了是自僱者以外,也可以把自己的人生當做公司來經營。 但在 ABZ...

about 1 month ago • 1 min read
Share this post