search
尋找貓咪~QQ 地點 桃園市桃園區 Taoyuan , Taoyuan

[ 平面理論教程 ] 詳細解析設計師應該如何去掌握主動權- 其他教程 - 骨子愛創意

教學主題: 詳細解析設計師應該如何去掌握主動權

大家好!! 小編今天來和大家分享關於 其他教程中的平面理論教程教學

今天的這個教學主題是: 詳細解析設計師應該如何去掌握主動權

這教學的重點為這幾點 [ 掌握,如何,應該,解析,設計師,詳細,設計,我們,一個,產品 ]

希望你可以從這幾點中領悟到修圖的精華

本文重點

懂得把控產品的設計師不僅能少改稿,設計成果會更加出色,但如果身在PM強勢的公司,設計師該如何把控流程,主導設計?今天金山的可風同學寫了一篇長文,將自己多年的經驗分享出來,文中多親身設計案例,實用性強,弱勢的設計師們,來進擊吧。

懂得把控產品的設計師不僅能少改稿,設計成果會更加出色,但如果身在PM強勢的公司,設計師該如何把控流程,主導設計?今天金山的可風同學寫了一篇長文,將自己多年的經驗分享出來,文中多親身設計案例,實用性強,弱勢的設計師們,來進擊吧。

可風f今天想和大家聊一聊設計師的煩惱,因為我自己是設計師,周圍的朋友也大部分都是做設計行業的,大家交流的時候難免吐吐槽,說說自己的煩惱。但是聽多了之後發現設計師的煩惱還是挺有規律的,無非就是這三大類:

1,太着急:經常早上提的需求下午就要,沒有時間認真打磨和研究,更別提什麼創新了。總是被需求方催着,只能草草了事,自己都不忍心看。

2,修改太多了:感覺對方也不知道要什麼,怎麼做都要被修改,大家都很糾結.

3,被指點江山:尤其是被不懂設計的人指點江山,經常提一些很主觀和細節的要求,感覺還不如讓他們自己做得了。




但是認真感受這些煩惱之後,發現一個更嚴重的問題就是:大部分設計師都沒有設計的主動權。圖是設計師在做,但是設計的過程和結果卻不是設計師自己能夠掌控的。

於是我就在想為什麼會造成這樣的問題,當然原因有很多,可是有一個很根本的原因就是在現在的互聯網設計流程中,設計師本身就是處於整個流程的下游。

詳細解析設計師應該如何去掌握主動權

大家可以看到上圖是我們常見的設計流程,需求方或用戶提出需求,產品經理整理需求,最後才反饋給設計師開始設計。這看似司空見慣,但是卻會造成一些問題:

1,信息滯后:大部分需求設計師都是最後一個知道的,也許在知道之前,產品經理和領導就已經討論完了,甚至有了基本的設計解決方案。設計在最後才介入,只能做一些執行的工作。

2,目標不清:因為設計師無法了解原始的場景,當時用戶的問題和需求點都沒有自己感受到,只是別人傳達的。那麼可能會被傳達少一些,或者加入很多主觀的想法歪曲了一些,這樣設計師所了解到的設計目標可能根本就不是一開始想要的。

3,進度失控:大部分情況下項目周期可能都是領導和產品經理訂好了,什麼時候立項、什麼時候測試什麼時候上線。等到某一天突然找設計師要圖的時候,天啊~完全沒有準備好!

尤其是像我們獵豹移動是一家產品經理為主導的公司,產品經理有很大的影響力和信息的壟斷性,表現到煩惱上就是——大家覺得產品經理太強勢了!但是後來我仔細想想其實這也不算什麼問題,百度也是工程師文化,阿里也是運營文化,估計除了蘋果以外設計師在哪裡都得面對這樣 的現實。

如何解決這些煩惱?

在聊如何解決的時候,我想說一下假如這些煩惱都已經解決了,假如有一種符合設計師的理想模式,那會是怎樣的?




1,設計師由接任務變為推動設計:傳統的情況我認為設計師都在接任務,接受別人的任務並且完成,這樣不斷的反覆。但是在理想模式下設計師可以推動自己認為美好和正確地事情去變為現實;

2,設計師自己掌控自己的時間:尤其是設計師可以為自己留出認真思考和創新的時間,而不是始終疲於奔命;

3,方案的通過率高:指的是我們只需要出那麼一兩稿,就可以基本確定大方向,不用一直繞圈子;

而在這種模式下,我覺得設計師已經不再是流程的下遊了,而是某些意義上來說,設計師在領導整個團隊推進產品設計的提升,這就是設計師掌握了主動權。

大家可能會覺得這種夢寐以求狀態實在太理想了,也可能會問到底應該怎麼做才能掌控主動權呢?其實我也沒有完全做到這種狀態,但是我們團隊始終在以這個目標不斷的嘗試和改進自己的工作方法,在很多情況下都已經產生了不錯的效果,所以想分享一下我們的經驗:




1,設計師要做到知己知彼,掌握全面的信息

我曾經做過瀏覽器的交互設計,我經常接到的需求一般會類似於 “做一個加載網頁的進度條”,要是平常可能大家就這麼去認真的研究這個進度條了。但是我們會首先放在整個產品架構上去看這個需求,進度條是屬於網頁速度體 驗的一個環境,那麼和安全、瀏覽器性能上有什麼關聯呢?又或者在表現形式上,加載的進度條和下載的進度條有什麼區別呢?

所以我們的設計師會維護一個產品的用戶體驗架構,看問題並不是只看一個點,而是看一個面,並且看到他們之間的聯繫。這樣可以提升我們的反應能力和設計的精準性,而要做到它就必須建立在有非常充分信息的基礎上。

1.1 我認為設計師要掌握的信息有三類,第一個是要了解產品的戰略方向。

具體表現就是產品的商業目標:為什麼要做這個產品?以及產品的策略:通過什麼方式來實現這個目標?




剛加入金山調入瀏覽器部門的時候,上班第一天我就問領導一個問題 “為什麼要做獵豹瀏覽器”,當時領導一副詫異的表情類似 “你一個美工幹嘛要問這個?”。後來經過長聊之後我們才溝通清楚,作為設計師,之後的每一項方案、每一個研究和思考的方向、每一次設計決策,都是為了幫助 實現你的產品目標。所以如果能溝通清楚讓大家都清晰才能夠更好的協作和執行,甚至讓設計師發揮自己的主動性來達成目標。

給大家舉個例子,一年之後我們進入海外市場,當時海外的瀏覽器市場還沒有飽和,移動瀏覽器的技術瓶頸也還沒有到。所以我們決定做一款“最快的手機瀏覽器”,依靠簡單極致的速度去贏得用戶的口碑。

但是可能很多人就問,“快”不是性能和開發的問題嗎?和設計有什麼關係?其實快不僅是性能,視覺上的簡潔輕巧,交互上的化繁為簡,都是用戶能真切感受到的“快”。

所以當時我們做的第一件事情就是把主題改成白色了。獵豹的品牌色一直是黑色和橙色,非常重的質感,老闆很喜歡。所以我們這個改動不是一般的難,一來它觸犯了品牌一致性的大忌,二來非常難說服老闆上個年代的審美觀。但是因為強烈的目標感,大家最終還是推進下來了這件事情。

詳細解析設計師應該如何去掌握主動權




然後設計師因為對目標的了解也發揮了很大的主動創新能力,比如在簡單App啟動過程中,我們為了讓App的啟動感覺更快,做了很多細節上的修改。

詳細解析設計師應該如何去掌握主動權

傳統上的App啟動分為上圖這幾個步驟,程序啟動是一定要等幾秒的,一般產品會選擇做一個品牌宣傳的頁面,比如UC這樣。但是我們當時選擇一張圖片,讓模擬加載出一般的“框架效果”,這樣用戶就會以為我們是一個逐漸加載的過程。

詳細解析設計師應該如何去掌握主動權

詳細解析設計師應該如何去掌握主動權




當然這也不是我們原創,只是我們為了快的目標,而最終選擇了這個方向。

另外一個步驟就是首頁的內容展現也會有一個加載,雖然很短但是如果不作處理的話就會顯示一個loading也不是很好。於是我們又用了一張圖片,是用戶上次退出的時候主屏的截圖來替代loading的小菊花,這樣過渡效果就柔和很多。

詳細解析設計師應該如何去掌握主動權

詳細解析設計師應該如何去掌握主動權

另外還有一個小細節,同樣的截圖,我們顏色確是不一樣的(下圖文本框),這樣一深一淺是模擬加載的時候內容漸隱展現出來的感覺。




詳細解析設計師應該如何去掌握主動權

所以就是這樣幾張簡單的圖,我們在感官上給了用戶順暢和快速啟動感受。

所以其實在實際工作中,產品的方向深刻的影響了設計師的每一個判斷和思考,同樣也影響了設計師的效率和成敗。有的時候我們只覺得管好眼前的事情或者分內的事情,殊不知反而會帶來更多的迷茫、爭執和不理解。

1.2 了解用戶反饋和數據

在傳統的流程下設計師大部分情況可能都不會直接接觸到數據和用戶反饋,而是經過運營或產品經理整理,或者好一點的公司還能有用研給一個結論。更有的同學覺得,數據和用戶反饋不就是產品經理和運營用到的嗎?設計主要還是靠美感和品位。




但是更多時候設計是解決問題的,問題的來源往往就來自於數據和用戶反饋。可是數據和反饋並不能直接給出設計師想要的目標,它們僅僅是素材,運營同學 可以從中看出如何改善運營活動,產品同學可以從中挖掘需求,所以設計同學也應該自己去研究和消化數據和用戶反饋來改進自己的設計。

我們團隊的流程通常是這樣的,有一位專門的同學每天收集來自各個渠道的用戶反饋然後發給團隊所有成員,如果大家有興趣的話,可以挖掘用戶的原文並且找到用戶的聯繫方式繼續深聊。如果數量多或者比較嚴重,則會在討論會上各個角色都提出自己的專業建議,並且討論項目排期和改進計劃。

數據也是一個道理,數據的漲跌會因為很多複雜的原因造成,各個角色也會參與和跟進到數據的變化的分析中。有的時候我們的設計師會做出很多種設計樣式小量測試,然後看數據的變化來得出最佳的設計方案。

所以這兩樣東西設計師不光是簡單地看:反饋的原始場景是什麼?反饋的是什麼樣的用戶?能否深挖這個反饋,和用戶聯繫?

也不僅僅是看而已:收集並且觀察,重要的還得跟進細節;長期保留作為以後設計決策的依據;長期觀察,提升自己對用戶和數據的理解;




1.3 了解項目計劃

設計師對項目計劃有很強的被動感,很多時候覺得反正你們定好我按照安排做就行了,不知道也不想知道別人都在幹什麼,但是這樣往往最終都給自己帶來了麻煩。

有一次周五下午一個產品經理找我說有一個很急的需求,希望我周一的時候能給出方案。當時我就懵了,這不是要我周末加班嗎? 說好的和妹子看電影什麼的。於是我反問他項目計劃,為什麼周一要方案。原來周一的時候產品經理例會,他要給產品總監彙報這個需求但是沒有原型無從說起。經 過了解后我們達成一致,我先給他一個粗略的方案,能夠表現出大概的交互方向,然後等之後在確認了我再補充上各種細節和分支,這樣即滿足他也不會耽擱我很 久。

所以設計師如果對項目計劃的各個節點都充分了解不但可以避免誤會和爭吵,還能提前準備和思考,把控自己的工作節奏。比如:

什麼時候可以定設計方向?(提前做好充足的準備,探索風格)




什麼時候開發要介入?(需要給出基本框架和布局)

什麼時候開發會細調界面?(需要給出細節和標註了)

什麼時候測試和上線?(要和開發一起調試實現效果)

上線之後效果的反饋周期?(幫助自己驗證和改進設計)

但是在了解和思考項目計劃的時候有一點需要注意的是,設計師的考量標準是目標和結果而不是項目計劃中對方的要求。經常有的項目計劃太 緊張讓我喘不過氣來,但是卻想要很高的結果。比如產品經理說希望改進界面大幅度提高用戶口碑,但是卻只給我半周的時間,如果我客觀分析了不行,我就會直接 告訴他說半周我能完成一個新的設計方案,但是絕對做不到想要的這個結果的。這是能力問題,要不你換個大價錢找個能做到的,這次逼我也沒有用啊。




2,設計師要明確設計目標

2.1 思考設計目標是什麼呢?我到底做這個設計方案是為了解決什麼事情?

首先 “解決方案” 絕對不是目標,我們大部分時候接收到的其實都是解決方案而不是目標。比如產品經理有的時候說:“你要新加一個按鈕,或者新加一個紅色的按鈕”。但是新加按鈕其實是為了為某個功能做一個入口,入口一定要是按鈕嗎?是不是banner,卡通圖形也可以?而要做紅色的按 鈕也許是為了強調這個入口,那麼強調的方式也可以有很多種,除了顏色以外,布局位置,周圍的留白,陰影和質感都可以起到強調作用。

所以有的時候設計師聽到需求方這麼具象的要求都很生氣,心裡想着 “哇靠明明和我們風格不符沒辦法這樣做好嗎?要不你來做 “,但是實際上都是因為互相都沒有深刻去挖掘目標。這樣的例子還有很多:

1,設計一個註冊流程 = 滿足用戶收藏的慾望 = 真的需要註冊嗎?

2,增加幾張啟動歡迎頁面 = 告訴用戶版本新功能 = 放在場景中引導是否更有效?

3,將banner做大一些 = 提升30%的轉化率 = 內容是否也有改進餘地?

2.2 為誰而設計?

我們做UE行業的人有一個單純而美好的錯誤,就是認為我們都是為用戶而設計的。但是現實很殘酷,除了用戶,我們還要考慮為公司的商業利益而設計,甚 至是為領導而設計。在做設計的時候如果沒有考慮到這兩點可能方案就被莫名其妙的拍死了,有的人還會因為挫折太多而開始反思自己的志向。

有一段時間我特別苦惱公司的商業化目標,因為以前一直埋頭做用戶口碑,想着把產品體驗做好就可以了。但是產品突然到了收割 期介入了很多“商業產品經理”,提出過很多超出自己底線和無理的需求。剛開始的時候我還一直不理解和反抗,但是仔細想想我才明白,商業化本身和用戶體驗不 衝突。所謂用戶體驗,本來就是在幫助公司實現商業價值的前提下,盡量讓產品保持好的體驗的。

而想明白了這個,就開始更積極的去想如何把商業化的體驗做好。比如提升廣告質量,在場景和使用路徑下做精準化投放等。其實很多人覺得商業化是萬惡之源,只是因為大家都打着商業化的旗號而懶于思考,見縫插針,簡單粗暴做事情罷了,而沒有真正的擁抱和思考它。

2.3 規劃目標的優先級

如果我們設計師接收到的目標只有一個,那幹活的時候就太輕鬆了,因為我們只要稍微挖掘就可以知道應該怎麼做。但是到現實中我們往往遭遇的矛盾就是感 覺通常目標都有好多,產品經理這也想要,那也想要,這也不能丟,那個也很重要,到底要怎麼辦?最有趣的段子就是需求方的要求是:高端大氣有檔次,低調奢華有內涵,簡約中帶着點霸氣,既體現歐式奢華又能傳承中國古韻…(笑)。所以我們通常接收到的需求,都是會包含很多目標的,我們要把這樣目標分解成優先級:

1,核心目標:核心目標只有一個,是最符合本次產品設計和改版根本緣由的。我通常會和產品經理說假設因為時間和能力有限,他提的所有的要求中我只能實現一個,他會怎麼砍?殘酷和艱難的抉擇留給對方自己,因為只有明確了唯一的核心目標,設計師才能在日後有什麼衝突和矛盾的時候做出爭取的抉擇和判斷。

2,兼顧目標:除了核心目標以外,需求方還會說很多“這些最好也需要達到”的目標,比如和品牌相統一,盡量保證開發性能之類的。對待兼顧的目標我的 原則是如果能實現我就盡量實現,但是實現不了或者與核心目標有衝突則果斷砍掉。有的時候設計師會和產品經理一起糾結在這些兼顧目標中去,糾結完其中一個又 糾結另外一個,所以如果之前已經和對方溝通過核心目標,當發生矛盾的時候大家砍掉就變得很自然。

3,有則更好:這個比較簡單,就是能做到最好了,需求方也不做特別要求。但是很多時候需求方認為只是有則更好的東西,到了設計師眼裡變成很重要的東 西,比如做的超華麗,可以發到網上無數點贊的那種。這就需要設計師理解設計的根本是幫助產品解決問題的,優先做好核心目標再思考在這個地方的提升會更受大 家歡迎一些。

那麼在現實中我是怎麼用這個思想去指導設計決策呢?

比如作為交互設計師,我可能會接到需求是要 “設計一個App的導航方式”。我會先把各種可能應用到的導航方式全部列出來,並且分析他們各自的優點和缺點。然後我判斷的依據是:它的優點是解決核心目標最佳的方案,而它的缺點又是可以被容忍的,這就是最合適的方案。

詳細解析設計師應該如何去掌握主動權

比如像上圖,如果我要設計的是一個像新聞一樣的沉浸閱讀App,就會傾向選擇抽屜式導航。而如果是強調不同模塊的互動,強調用戶去參與更多功能的,就會選擇普通的底部tab形式。

想做到這一點,多了解導航的基礎知識是非常有必要的呦:《交互基礎知識科普!帶你認識最熱門的12種導航模式》

2.4 保持目標的導向性

給大家舉一個例子,有一次我去找領導討論,想確定一個導航方式的時候:

詳細解析設計師應該如何去掌握主動權

我想很多設計師也會這樣吧,發現自己在和外部討論的時候總是很容易被說服,或者發現最終討論的結果不是一回事,自己又在不停的改一些無關緊要的東西,方案為什麼不能很快被完結呢?其實就是因為在後續的推進和溝通中沒有保持目標的導向性。

我的經驗是,先聚焦在如何推進和解決最關鍵的部分上,暫時忽略分支和細節。比如在對一些設計稿的時候領導和其他人總會針對一些小地方提出自己的建 議,我都會拉回來說咱們這次主要是定xxx,其他地方後續我們可以慢慢修改。這樣就相當於把自己的工作分了步驟,不至於繞一大圈而丟失很多效率。

3,加強設計的推動力

我一直有一種觀點,就是認為如果沒有被最終實現的設計不能算作真正的設計作品。因為從本質上來說它沒有帶來任何價值,也沒有解決任何用戶的問題,只 是流於形式和藝術。所以要做到這將設計落實下去,設計師就應該不斷地思考如何把提升自己的推動力,這些不僅僅考驗的是出圖的能力,對設計師的溝通力和把控 力也有了很高的要求。

我認為首先要做到我之前說的兩點(也就是了解信息和明確目標),另外還可以分享一些提升推進力的具體流程和方法:

3.1 更前置的開展設計工作

場景A:PM來找到設計師說 :“小U,老大說這個地方體驗不好,咱們改一下吧,後天要發版所以你明天給我方案好了。”

場景B:設計師找到PM同學說 :“小P,最近我們的用研發現A流程的體驗還有問題啊,我們想了一些解決方案並且有一個不錯的,所以你看看什麼時候能夠協調出開發資源呢? ”

大家覺得,哪一個場景更好?

我們認為要做到場景B,就得有一套前置開展設計的流程和方法。我們團隊的設計師在看待設計工作的時候並不是看成一個點,而是看成一個面,一套體系。 比如說我們會維護一個用戶體驗地圖,將產品的使用流程分解,去標註每個節點都有什麼做的好的地方和差的地方,這樣就可以直觀的反應出哪裡的體驗還有改進的 餘地。加上之前我們對信息的收集和目標的確定,設計師在產品經理提出具體的要求前,就已經可以大概知道哪些地方需要改進和提升了。

用戶地圖是很實用的設計工具,建議設計師們都掌握起來!《為設計加分:手把手教你有效地做用戶體驗地圖》

詳細解析設計師應該如何去掌握主動權

接下來的我們會把問題池中的重要問題提煉出來,然後去規劃它的解決方案。比如UX內部自己開展一些用研計劃、概念稿、可用性測試,直到我們認為出現 了一個不錯的可解決的方案。接下來就是在合適的時間去推動整個產品團隊實現這個方案,比如在技術成熟,資源有富餘,或者領導正好關心這一塊的時候適時的提 出來。而暫時還沒有推進的方案我們則會保留下來,這樣下次有人再提出來的時候我們不但已經非常了解了,而且可以很快解決問題。

詳細解析設計師應該如何去掌握主動權
貼心提醒: 按Ctrl+Alt+Z和Ctrl+Shift+Z組合鍵分別為在歷史記錄中向後和向前 ( 或者可以
使用歷史面板中的菜單來使用這些命令 )。結合還原 ( Edit/Undo )命令使
用這些熱鍵可以自由地在歷史記錄和當前狀態中切 換。

3.2 主動發起和跟進

之前講項目計劃的時候也提到,很多設計師都只關心自己這一塊的工作,而沒有去Push大家的習慣,比如圖已經做好了一封郵件丟出去就不管了,反正等結果就好了。但是實際上我就遇到過很多坑,比如丟出去圖產品經理沒有反饋,等到好幾天後又突然反饋說不行再改改,但是離完結時間也沒多久了。或者又一次其他人選了一個站在設計角度不是最優的方案,我當時也因為懶也就沒有再去爭了,但是最後被老大看到還是痛批了一頓老老實實改。

所以說到底設計師根本是為了自己的設計結果和效果負責的,而不僅僅為了完成當下的任務,設計師還得自己去發起和跟進自己的設計。

1)主動發起設計評審:

完成了方案就及時的找相關的人討論,而且要發起會議,不是簡單地丟一封郵件給對應的產品經理,這些人可能包括領導,開發,測試等。

為什麼要這樣呢?因為點對點的溝通沒有面對面的溝通效率來的高,大家可以集中把意見都提出來,省下一個環節一個環節的麻煩。

2)增加大家的參與感:

就是在正式的評審環節前,讓各自利益相關的人看一看,聽聽他們的想法和建議。

大家有沒有這樣的經歷?開發如果覺得這個設計方案不好實現,往往不會說開發難實現,而是會說這個設計不好看或者體驗差。這因為在公開場合示弱往往是很不好意思的事情,所以提前去了解一下大家的想法和建議,這樣才可以平衡各方的利益,免得被一次拍死。而且如果你私下採納過大家的想法,對於其他人就有種 “自己也參與了這個設計,這也是我的方案” 的感覺,是可以潛在的獲得更多支持的。

3)跟進開發實現的效果:

很多人會把跟進實現的工作丟給產品經理或者項目經理,但是其實他們是不懂設計的,也沒有像素眼,很多細節點理解不到位。所以設計師自己去盯去看還是很重要的,用戶在用得不爽的時候只會罵設計師,才不會記得你的設計稿呢。另外在獵豹招聘設計師的時候,能有實現的產品我們都只看實現的效果,如果對方說是實現不好,我們都會反問 “那為什麼你沒有把控好實現的效果?”

3.3 管理產品經理




這一點聽起來很奇怪吧?明明是PM管理我們吧?尤其是在獵豹移動和360這樣產品經理強勢到類似領導的公司,或者很多小團隊中沒有獨立的UX部門, 設計師本身就依附在產品經理下面。但是我想說其實產品經理只是設計師順利工作的一個因素罷了,以正確的方式面對產品經理的需求,並且適當的提出質疑和建 議,獲得他們的信任。在某些程度上,還可以利用產品經理對整體需求和資源的把控優勢來推進很多事情。

所以轉變觀念很重要。

Review

最後說了這麼多,其實核心的觀點就是:了解信息 – 明確目標 – 推進設計,如果要再深入展開的話會還能有很多的內容和案例可以講。但是大家一定有一個疑問:我平時都忙的要死,哪還有時間和精力去做這麼多事情?

詳細解析設計師應該如何去掌握主動權
貼心提醒: 使用選框工具( Marquee Tools )的時候,按住Shift鍵可以劃出 正方形和正圓
的選區;按住Alt鍵將從起始點為中心勾劃選區。

其實我認為大部分人,真正有效的工作時間都只有40%,而浪費在爭吵、等待、理解錯誤和反覆修改的時間上確是大部分。所以與其浪費時間做錯誤的事情,還不如多多思考該怎樣改進自己的工作方法,怎樣養成一些好的習慣。

看完小編分享的教學之後 是不是對平面理論教程中的其他教程教學更熟悉了呢?

希望我們所介紹的 詳細解析設計師應該如何去掌握主動權 這教學會喜歡

文章標題: 骨子愛創意- 詳細解析設計師應該如何去掌握主動權–轉載請註明來源處

本教學分類為平面理論教程中的 其他教程相關教學

文章相關關鍵字為: 掌握,如何,應該,解析,設計師,詳細,設計,我們,一個,產品

本文永久連結 :詳細解析設計師應該如何去掌握主動權

本文轉載自 :VIA



熱門推薦

本文由 designhtd01com_0 提供 原文連結

寵物協尋 相信 終究能找到回家的路
寫了7763篇文章,獲得2次喜歡
留言回覆
回覆
精彩推薦