# PC产品移动化

By [Untitled](https://paragraph.com/@0x441b576747f668b38dad158e645fc08e97da75a3) · 2022-05-25

---

### 0\. 前言

随着移动设备的普及，为了拓展产品的使用场景，PC产品移动化成为了一种趋势；但是PC和移动在设备规格、使用场景、用户操作习惯等方面存在很多差异、所以移动化并不能简单的照着PC端的内容照搬，需要根据实际情况，多方面的进行分析、评估。

本文将从产品的五要素，讲述我在做PC产品移动化时遇到的一些问题以及思考。与大家进行分享。

### 1\. 战略层

### 为什么要移动化

1.  移动化办公，信息传递更快更及时，不受场地限制，加快工作节奏，提高工作效率。
    
2.  随着移动互联网的迅猛发展，用户花费在移动设备上的时间越来越多，PC产品移动化成为一种趋势。
    
3.  互联网浪潮下长期培养的用户习惯，让用户更倾向于通过移动设备来解决问题。
    

### 2\. 范围层

### 需求分析

产品移动化，并不是简单的将PC端的内容照搬到移动端，需要根据实际情况，多方面的进行分析、评估。

需求分析-产品内容

*   \*\*用户的实际需求：\*\*哪些内容需要移动化，哪些没必要，需要进行逐一的筛选，最好有调研业务背景的支持。
    
*   \*\*移动端的局限性：\*\*一些复杂功能，例如开药、预约，因为涉及到的模块很多，比较复杂。可以考虑适当的简化产品功能，将部分功能更置于PC端进行配置。
    
*   \*\*开发优先级：\*\*对于一些使用频率不高的功能，前期可以考虑不上，等App上线后，再根据用户反馈和重新评估开发资源做进一步决策。
    

### 3\. 结构层

根据上一步需求分析确定的“产品范围”后，进行导航、框架的构建与设计，最终输出移动App的**信息架构图**。

![](https://storage.googleapis.com/papyrus_images/0d0cc889b5688ea3face11c9304eea03dc1e666caadfab38436234032e4febd2.jpg)

架构图

**4\. 框架层**

### 页面样式

产品移动化，前期需要做的准备工作很多，下面开始讲产品设计的方法。 我对于B端产品，接触比较多的是ERP、平台产品这一块，所以接下来会更多的拿这方面的内容来举例，但是方法与技巧是共通的。

### 1） 表格

![](https://storage.googleapis.com/papyrus_images/6e206267de3303dd793b3d5f9965aec8a8532856ba6c1decdf0d8bb3e19ddaa6.jpg)

PC端表格

PC端的表格，通常都**比较宽**，**字段多**，**数据信息量大**。如何将这么“大”的表格在移动端进行展示呢？最简单的就是直接将表格“搬到”移动端，但这样肯定是不行的。经过一番思考后，进行如下的尝试：

![](https://storage.googleapis.com/papyrus_images/087e11e916a23ae8a0cc7123d8b165c1adea10add94e7b92be5857ed38382944.jpg)

表格移动化解决方案

**a. 删减字段**，挑几个重要的字段进行展示，其它字段删除。这样虽然能够较好的在移动端展示，但却无法满足业务需求。

**b. 加滚动条**，该方案在满足业务功能上没有问题。但在操作体验上，首先这是PC端的交互方式，不适合用在移动端；其次，“可拖动”的区域比较小，当纵向数据较多时，滚动条可能出现在下一屏。再者，左右拖动是一个动态的过程，用户需要刻意的对拖动前后的信息建立连系。

**c. 表格显示在一块固定的区域**。 当左右滑动时，最左侧的一列固定且悬浮，其它列整体左右滑动； 当上下滑动时，最上面的一行固定且悬浮，其它行整体上下滑动。 该方案把表格移动化遇到的大部分问题都解决了。但它的缺点是，开发成本很高，且对移动设备的硬件也有一定的要求，特别是滑动时可能会出现卡顿。

通过对a、b、c三种设计方案的利弊分析，发现都不是很理想。当发现照搬PC端样式，通过交互无法解决表格展示时，我就开始重新思考表格是什么？表格是展示和传递数据信息的**载体**。

既然是载体，也就是说在移动端的数据信息可以采用其它更合适的载体来承载。换句话说，就是可以尝试在移动端采用其它的形式来展示PC端的表格信息。

接下来通过和业务人员沟通，提取出对于药物分发最关键的信息：药品信息、取发药/退药日期。在移动场景下，可以先将最关键的信息展示出来，其它的信息“**转移**”到下级页面显示。

![](https://storage.googleapis.com/papyrus_images/81b8137ceba34f1b3a8c4833e190b624f3380f3417dfb331fef4b018d1e279b9.jpg)

移动端表格

### 2） 多字段显示

移动端内容详情页对于多字段的展示，主要有以下几种形式：

*   **A类**：适用于字段个数比较多的情况。使用要求：字段名长度在4~10个字符之间。
    
*   **B类**：适合直接展示在“首屏”的重要字段。使用要求：字段意义明确且数量少。
    
*   **C类**：属于通用型的，比较适合于字段值为数字类的字段，也适合字段名和值长度相差比较大。\\
    

![](https://storage.googleapis.com/papyrus_images/33e4137ee6a92ac0c8d10518d8840ab4ce7650a1bede3f43bf0730e332efdbac.jpg)

移动端多字段显示

### 3） 屏幕尺寸

相对于PC端的屏幕，移动端就显得小的多，加之PC产品的信息量也比较多，所以在设计的过程中，要特别注意“**首屏**”所承载的信息量，要把握好度。内容过多，增加了用户获取信息的难度，内容过少，频繁操作，也不合适。

对于**一个页面内**的信息量（可能有多屏），也需要进行控制。最重要的信息要第一时间呈现在用户眼前，一些重要程度不高的信息，可以进行“隐藏”（折叠）。

![](https://storage.googleapis.com/papyrus_images/df32f1dfb1acdd0daf72eed516bd77a3789167623e06714f69f3bd3d8deea145.jpg)

屏幕尺寸

### 5\. 表现层

### 设计规范

一般来说，为了适应移动端不同系统的用户操作习惯，APP应该根据不同平台的设计规范分别展开设计。

工作中进行移动应用设计时，理想的状态：有足够的时间，分别Android和iOS出一套设计方案进行开发。但现实往往是,时间紧、预算少、人力资源短缺，要求同时开发运行Android和iOS设备上的App。

此时可以考虑：

1）**统一设计风格**。Android和iOS一套设计方案，节省时间，降低开发成本。

2）**微调设计方案**。设计方案出来后，根据Android和iOS平台规范的特点进行一些微调，例如一些控件可以直接用原生的（日期弹层，提示框，搜索Icon等），一方面减少开发人员重新“造轮子”，另一方面也能使得App在不同的平台上显得自然些。

### 6\. 其他

### 网络状态

网络状态，每个移动App都需要处理的问题，主要内容就是在不同网络情况下，进行相应的提示与告知。主要有这几种情况：

1）**无网络** — 进行网络未连接或网络异常提示

2）**有网**

a. 加载中 — 加载状态的提示（转动的小圈圈、进度条等）

*   可采用“懒加载”，避免数据过多导致加载时间过长；
    

b. 加载失败 — 失败告知

[crowdfund://undefined?features=overview,backers](https://etherscan.io/address/undefined)

[crowdfund://0x441b576747F668B38daD158E645fC08e97DA75a3?features=](https://etherscan.io/address/0x441b576747F668B38daD158E645fC08e97DA75a3)

---

*Originally published on [Untitled](https://paragraph.com/@0x441b576747f668b38dad158e645fc08e97da75a3/pc)*