<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          SSM框架實戰-搭建自己的個人博客1-基礎架構搭建

          前端達人

          前言

          本系列文章主要通過從零開始搭建自己的個人博客,來加深對SSM框架的學習與使用,了解一個系統從提出到設計-到開發-到測試-部署運行的過程,并記錄在搭建過程中的學習心得、遇見的錯誤及解決方式。

          個人博客的主要功能有:

          1. 博客列表展示:文章按照時間順序(時間倒序:最新最先展示)列表展示
          2. 博客文章詳情展示:展示文章全部內容,包含:作者、創建時間、所屬目錄、標簽、文章標題、內容
          3. 用戶權限管理:游客只能瀏覽文章、管理員可以發布文章、文章下線處理
          4. 添加文章功能:支持富文本編輯??梢哉{整字體大小、樣式、鍵入代碼等功能

          界面展示:

          前臺博客列表界面

          前臺博客列表頁面.png

          博客詳情頁面

          博客詳情頁面.png

          后臺管理頁面 

           

          登錄頁面

           

          后臺管理頁面.png

          項目技術簡介

          系統實現的功能點

          1. 用戶權限管理:普通的用戶(游客)只能瀏覽文章、管理員用戶可以發布文章、文章管理
          2. 博客列表展示:文章按照發布時間順序(按照時間倒敘)展示 :博客類別、標簽、博客名稱、作者名、發布時間、閱讀數量、博客的內容概括
          3. 博客詳情頁面:博客名稱、作者、時間、博客內容、標簽
          4. 博客后臺列表:博客檢索(類別、標簽、博客名稱)、博客列表(博客id、博客類別、標簽、時間)、博客操作
          5. 新增博客功能:支持富文本編輯:可以調整大小、樣式等

          服務端技術

          核心框架:Spring:5.2.8.RELEASE

          web框架:SpringMVC:5.2.8.RELEASE

          持久層框架:Mybatis 3.2.4

          數據庫連接池:阿里druid:0.2.6

          數據庫:MySQL5.XX

          JSON數據處理:谷歌gson 2.3

          前端技術

          jsp

          Ajax

          前端框架:bootstrap

          富文本編輯器:百度UEditor

          數據庫的設計

          • 用戶表:賬號id、賬號名稱、賬號密碼
          • 博客表:博客id、博客名稱、博客內容、發布時間、閱讀量、類別id、狀態
          • 博客/標簽對應表:博客id、標簽的id
          • 標簽表:標簽id、標簽名稱(博客和標簽:一對多:一個博客可以對應多個標簽)
          • 類別表:類別ID、類別名稱(博客和類別:一對一:一個博客對應一個類別)

          創建SQL語句:

           
          
          1. DROP TABLE IF EXISTS `t_article`;
          2. CREATE TABLE `t_article` (
          3. `id` int(11) NOT NULL AUTO_INCREMENT,
          4. `categoryId` int(11) NOT NULL COMMENT '分類Id',
          5. `title` varchar(40) NOT NULL COMMENT '標題',
          6. `content` blob NOT NULL COMMENT '內容',
          7. `description` varchar(500) NOT NULL COMMENT '文章簡介 用于列表顯示',
          8. `statue` int(11) NOT NULL DEFAULT '0' COMMENT '狀態 0:正常 1:不可用',
          9. `author` varchar(15) DEFAULT 'tulun' COMMENT '作者',
          10. `createTime` datetime NOT NULL COMMENT '發表時間',
          11. `showCount` int(11) NOT NULL DEFAULT '0' COMMENT '瀏覽量',
          12. PRIMARY KEY (`id`)
          13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='文章表';
          14. -- ----------------------------
          15. -- Table structure for t_article_image
          16. -- ----------------------------
          17. DROP TABLE IF EXISTS `t_article_image`;
          18. CREATE TABLE `t_article_image` (
          19. `id` int(11) NOT NULL AUTO_INCREMENT,
          20. `imageUrl` varchar(100) NOT NULL COMMENT '圖片地址',
          21. `articleId` int(11) NOT NULL COMMENT '文章Id',
          22. PRIMARY KEY (`id`,`articleId`)
          23. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='文章圖 主要用于列表瀏覽';
          24. -- ----------------------------
          25. -- Table structure for t_tag
          26. -- ----------------------------
          27. DROP TABLE IF EXISTS `t_tag`;
          28. CREATE TABLE `t_tag` (
          29. `id` int(11) NOT NULL AUTO_INCREMENT,
          30. `tagName` varchar(25) NOT NULL COMMENT '標簽名稱 唯一',
          31. PRIMARY KEY (`id`),
          32. UNIQUE KEY `tagName_UNIQUE` (`tagName`)
          33. ) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8 COMMENT='標簽表';
          34. -- ----------------------------
          35. -- Table structure for t_article_tag
          36. -- ----------------------------
          37. DROP TABLE IF EXISTS `t_article_tag`;
          38. CREATE TABLE `t_article_tag` (
          39. `articleId` int(11) NOT NULL COMMENT '文章Id',
          40. `tagId` int(11) NOT NULL COMMENT '標簽Id',
          41. PRIMARY KEY (`articleId`,`tagId`)
          42. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='文章標簽中間表';
          43. -- ----------------------------
          44. -- Table structure for t_category
          45. -- ----------------------------
          46. DROP TABLE IF EXISTS `t_category`;
          47. CREATE TABLE `t_category` (
          48. `id` int(11) NOT NULL AUTO_INCREMENT,
          49. `categoryName` varchar(20) NOT NULL COMMENT '分類名稱 唯一',
          50. `iconClass` varchar(45) NOT NULL COMMENT '圖標樣式',
          51. `aliasName` varchar(20) NOT NULL COMMENT '別名 唯一 比如新聞 就用News 代替 欄目Id不顯示在url中',
          52. `sort` int(11) NOT NULL DEFAULT '0' COMMENT '排序 (0-10)',
          53. PRIMARY KEY (`id`),
          54. UNIQUE KEY `aliasName_UNIQUE` (`aliasName`),
          55. UNIQUE KEY `categoryName_UNIQUE` (`categoryName`)
          56. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分類表 只支持一級分類 如果需要分多個層次 用標簽來協助實現';
          57. -- ----------------------------
          58. -- Table structure for t_manager
          59. -- ----------------------------
          60. DROP TABLE IF EXISTS `t_manager`;
          61. CREATE TABLE `t_manager` (
          62. `id` int(11) NOT NULL AUTO_INCREMENT,
          63. `userName` varchar(25) NOT NULL COMMENT '用戶名',
          64. `password` varchar(45) NOT NULL,
          65. PRIMARY KEY (`id`)
          66. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

          image.png

          框架結構搭建

          SSM項目腳手架搭建

          搭建如下框架結構:

          目錄說明:

           
          
          1. 目錄說明:
          2. |-src
          3. |--mian
          4. |---java JAVA源代碼根目錄
          5. |----com
          6. |-----tulun
          7. |------model 存放pogo類:基本基本的getter和setter方法
          8. |------controller 展示層類包路徑:前端用戶請求映射到該包路徑下類的實現
          9. |------service 業務邏輯層包路徑:業務邏輯實現,調用dao層服務
          10. |------dao 數據庫操作層包路徑:提供對數據庫的操作類與方法
          11. |------util 工具類包路徑
          12. |---resource 配置文件根目錄
          13. |----myatis mybatis接口對應配置文件目錄
          14. |----spring-XXX.xml SSM中mybatis、spring核心、springMVC的全局配置文件
          15. |--webapp 前端頁面內容根目錄
          16. |---WEB-INF
          17. |----web.xml 前端頁面必要配置文件
          18. |-pom.xml maven的配置文件

          測試Demo

          主要完成各個層之間的連接映射,完成從t_manager表中讀取數據并進行回顯

           

          POJO類

          根據數據庫表t_manager,創建User類

           
          
          1. package com.tulun.model;
          2. /**
          3. * Description :
          4. * Created by Resumebb
          5. * Date :2021/4/17
          6. */
          7. public class User {
          8. private Integer id;
          9. private String name;
          10. private String passwd;
          11. public Integer getId() {
          12. return id;
          13. }
          14. public void setId(Integer id) {
          15. this.id = id;
          16. }
          17. public String getName() {
          18. return name;
          19. }
          20. public void setName(String name) {
          21. this.name = name;
          22. }
          23. public String getPasswd() {
          24. return passwd;
          25. }
          26. public void setPasswd(String passwd) {
          27. this.passwd = passwd;
          28. }
          29. }

          Spring核心配置文件

          這里用到了阿里巴巴的druid連接池

           
          
          1. <beans xmlns="http://www.springframework.org/schema/beans"
          2. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          3. xmlns:context="http://www.springframework.org/schema/context"
          4. xsi:schemaLocation="http://www.springframework.org/schema/beans
          5. http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
          6. http://www.springframework.org/schema/context
          7. http://www.springframework.org/schema/context/spring-context-3.0.xsd">
          8. <!--開啟注解-->
          9. <context:component-scan base-package="com.tulun"/>
          10. <!--配置數據源:借助連接池druid-->
          11. <bean id ="dataSource" class="com.alibaba.druid.pool.DruidDataSource">
          12. <!--注入屬性-->
          13. <property name="url" value="jdbc:mysql://localhost:3306/test"/>
          14. <property name="username" value="root"/>
          15. <property name="password" value="123456"/>
          16. </bean>
          17. <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
          18. <property name="dataSource" ref="dataSource"/>
          19. <!--注入mapper映射文件-->
          20. <property name="configLocation" value="classpath:spring-mybatis.xml"></property>
          21. <property name="mapperLocations" value="classpath:mapper/*.xml"/>
          22. </bean>
          23. <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
          24. <property name="basePackage" value="com.tulun.dao"/>
          25. <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
          26. </bean>
          27. </beans>

          Spring-Mybatis配置文件

           
          
          1. <?xml version="1.0" encoding="UTF-8" ?>
          2. <!DOCTYPE configuration
          3. PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
          4. "http://mybatis.org/dtd/mybatis-3-config.dtd">
          5. <!--根標簽-->
          6. <configuration>
          7. </configuration>

          SpringMVC配置文件

           
          
          1. <?xml version="1.0" encoding="UTF-8"?>
          2. <beans xmlns="http://www.springframework.org/schema/beans"
          3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          4. xmlns:context="http://www.springframework.org/schema/context"
          5. xmlns:mvc="http://www.springframework.org/schema/mvc"
          6. xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
          7. http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.1.xsd
          8. http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-4.1.xsd">
          9. <!--掃描controller寫注解-->
          10. <context:component-scan base-package="com.tulun.controller"/>
          11. <!--配置映射器-->
          12. <mvc:annotation-driven/>
          13. <!--配置視圖解析器-->
          14. <!--視圖解析器-->
          15. <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
          16. <!--jsp頁面前綴-->
          17. <property name="prefix" value="/WEB-INF/jsp/"/>
          18. <!--jsp后綴-->
          19. <property name="suffix" value=".jsp"/>
          20. <property name="viewClass" value="org.springframework.web.servlet.view.freemarker.FreeMarkerView"/>
          21. </bean>
          22. </beans>

          web配置文件

           
          
          1. <?xml version="1.0" encoding="UTF-8"?>
          2. <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
          3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          4. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
          5. http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
          6. <context-param>
          7. <param-name>contextConfigLocation</param-name>
          8. <param-value>classpath:spring-core.xml</param-value>
          9. </context-param>
          10. <listener>
          11. <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
          12. </listener>
          13. <!--前端控制器-->
          14. <servlet>
          15. <servlet-name>myBolg</servlet-name>
          16. <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
          17. <!--將springMVC的配置文件進行配置-->
          18. <init-param>
          19. <param-name>contextConfigLocation</param-name>
          20. <param-value>classpath:spring-mvc.xml</param-value>
          21. </init-param>
          22. </servlet>
          23. <servlet-mapping>
          24. <servlet-name>myBolg</servlet-name>
          25. <url-pattern>/</url-pattern>
          26. </servlet-mapping>
          27. </web-app>

          pom依賴

           
          
          1. <dependencies>
          2. <dependency>
          3. <groupId>junit</groupId>
          4. <artifactId>junit</artifactId>
          5. <version>4.11</version>
          6. <scope>test</scope>
          7. </dependency>
          8. <!-- spring依賴-->
          9. <dependency>
          10. <groupId>org.springframework</groupId>
          11. <artifactId>spring-core</artifactId>
          12. <version>5.2.8.RELEASE</version>
          13. </dependency>
          14. <dependency>
          15. <groupId>org.springframework</groupId>
          16. <artifactId>spring-context</artifactId>
          17. <version>5.2.8.RELEASE</version>
          18. </dependency>
          19. <dependency>
          20. <groupId>org.springframework</groupId>
          21. <artifactId>spring-beans</artifactId>
          22. <version>5.2.8.RELEASE</version>
          23. </dependency>
          24. <dependency>
          25. <groupId>org.springframework</groupId>
          26. <artifactId>spring-expression</artifactId>
          27. <version>5.2.8.RELEASE</version>
          28. </dependency>
          29. <!--web依賴/spring mvc依賴-->
          30. <dependency>
          31. <groupId>org.springframework</groupId>
          32. <artifactId>spring-webmvc</artifactId>
          33. <version>5.2.8.RELEASE</version>
          34. </dependency>
          35. <dependency>
          36. <groupId>org.springframework</groupId>
          37. <artifactId>spring-web</artifactId>
          38. <version>5.2.8.RELEASE</version>
          39. </dependency>
          40. <dependency>
          41. <groupId>javax.servlet</groupId>
          42. <artifactId>javax.servlet-api</artifactId>
          43. <version>3.1.0</version>
          44. </dependency>
          45. <!--tomcat servlet api -->
          46. <dependency>
          47. <groupId>jstl</groupId>
          48. <artifactId>jstl</artifactId>
          49. <version>1.2</version>
          50. </dependency>
          51. <dependency>
          52. <groupId>taglibs</groupId>
          53. <artifactId>standard</artifactId>
          54. <version>1.1.2</version>
          55. </dependency>
          56. <!--mybatis依賴-->
          57. <dependency>
          58. <groupId>org.mybatis</groupId>
          59. <artifactId>mybatis</artifactId>
          60. <version>3.4.1</version>
          61. </dependency>
          62. <dependency>
          63. <groupId>mysql</groupId>
          64. <artifactId>mysql-connector-java</artifactId>
          65. <version>5.1.39</version>
          66. </dependency>
          67. <!-- 整合-->
          68. <dependency>
          69. <groupId>org.mybatis</groupId>
          70. <artifactId>mybatis-spring</artifactId>
          71. <version>1.3.0</version>
          72. </dependency>
          73. <!-- 連接池-->
          74. <dependency>
          75. <groupId>com.mchange</groupId>
          76. <artifactId>c3p0</artifactId>
          77. <version>0.9.5.2</version>
          78. </dependency>
          79. <dependency>
          80. <groupId>org.springframework</groupId>
          81. <artifactId>spring-tx</artifactId>
          82. <version>5.2.8.RELEASE</version>
          83. </dependency>
          84. <dependency>
          85. <groupId>org.springframework</groupId>
          86. <artifactId>spring-jdbc</artifactId>
          87. <version>5.2.8.RELEASE</version>
          88. </dependency>
          89. <dependency>
          90. <groupId>javax.servlet.jsp.jstl</groupId>
          91. <artifactId>jstl</artifactId>
          92. <version>1.2</version>
          93. </dependency>
          94. <dependency>
          95. <groupId>javax.servlet</groupId>
          96. <artifactId>servlet-api</artifactId>
          97. <version>2.5</version>
          98. </dependency>
          99. <dependency>
          100. <groupId>com.google.code.gson</groupId>
          101. <artifactId>gson</artifactId>
          102. <version>2.3</version>
          103. </dependency>
          104. <dependency>
          105. <groupId>com.alibaba</groupId>
          106. <artifactId>druid</artifactId>
          107. <version>0.2.6</version>
          108. </dependency>
          109. <dependency>
          110. <groupId>commons-logging</groupId>
          111. <artifactId>commons-logging</artifactId>
          112. <version>1.1.1</version>
          113. </dependency>
          114. <dependency>
          115. <groupId>commons-configuration</groupId>
          116. <artifactId>commons-configuration</artifactId>
          117. <version>1.9</version>
          118. </dependency>
          119. </dependencies>

          UserMapper

           
          
          1. import com.tulun.model.User;
          2. /**
          3. * Description :
          4. * Created by Resumebb
          5. * Date :2021/4/22
          6. */
          7. public interface UserMapper {
          8. public User getUserById(Integer id);
          9. }

          UserService

           
          
          1. package com.tulun.service;
          2. import com.tulun.model.User;
          3. import com.tulun.dao.UserMapper;
          4. import org.springframework.beans.factory.annotation.Autowired;
          5. import org.springframework.stereotype.Service;
          6. /**
          7. * Description :
          8. * Created by Resumebb
          9. * Date :2021/4/19
          10. */
          11. @Service
          12. public class UserService {
          13. @Autowired
          14. private UserMapper userMapper;
          15. public User getUserById(Integer id){
          16. if(id < 0)
          17. return new User();
          18. return userMapper.getUserById(id);
          19. }
          20. }

          UserController

          查詢t_manager中的id為1的數據進行顯示

           
          
          1. package com.tulun.controller;
          2. import com.tulun.model.User;
          3. import com.tulun.service.UserService;
          4. import org.springframework.beans.factory.annotation.Autowired;
          5. import org.springframework.stereotype.Controller;
          6. import org.springframework.web.bind.annotation.RequestMapping;
          7. import org.springframework.web.bind.annotation.ResponseBody;
          8. /**
          9. * Description :
          10. * Created by Resumebb
          11. * Date :2021/4/22
          12. */
          13. @Controller
          14. public class UserController {
          15. @Autowired
          16. private UserService userService;
          17. @RequestMapping("/testUser")
          18. @ResponseBody
          19. public User testUser(){
          20. User user = userService.getUserById(1);
          21. return user;
          22. }
          23. }

          UserMapper.xml

           
          
          1. <?xml version="1.0" encoding="UTF-8" ?>
          2. <!DOCTYPE mapper
          3. PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
          4. "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
          5. <mapper namespace="com.tulun.dao.UserMapper">
          6. <resultMap id="UserMap" type="com.tulun.model.User">
          7. <result property="id" column="id"></result>
          8. <result property="name" column="userName"></result>
          9. <result property="passwd" column="password"></result>
          10. </resultMap>
          11. <select id="getUserById" parameterType="int" resultMap="UserMap">
          12. select * from t_manager where id=#{id}
          13. </select>
          14. </mapper>

          運行結果

           

          錯誤記錄

          運行的界面顯示unkown the request

           原因是因為端口被占用了,更改服務器的端口號就可以了。

          出現這個錯誤就要檢查SQL查詢語句,數據源的配置是否正確,經檢查我報這個錯是因為SQL查詢語句manager寫成了manger,用戶名密碼不對也會報這個錯。

          類似這種錯,一是檢查@Service有沒有加上,二是檢查映射文件有沒有頂行寫,第一行不能有空行。

          轉自:csdn。作者:resumebb

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          centOS7殺死進程命令

          前端達人

          查看當前所有正在運行的進程,可以看到80端口被httpd占用了(80端口希望分配給nginx使用,而不是httpd)

          netstat -tpnul

           

          這里以殺死httpd進程為例:

          先查看 httpd 進程 

          flaskApi) [root@67 flaskDemo]# ps aux |grep httpd  root      6732  0.0  0.0 230488  5252 ?        Ss   8月06   2:27 /usr/sbin/httpd -DFOREGROUND
          apache 22570  0.0  0.0 232572  3888 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 22571  0.0  0.0 232572  3888 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 22572  0.0  0.0 232572  3904 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 22573  0.0  0.0 232572  3904 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 22574  0.0  0.0 232572  3900 ?        S    9月15   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 27544  0.0  0.0 232572  3896 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 27546  0.0  0.0 232572  3900 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 27548  0.0  0.0 232572  3172 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 27550  0.0  0.0 232572  3172 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
          apache 27552  0.0  0.0 232572  3172 ?        S    15:41   0:00 /usr/sbin/httpd -DFOREGROUND
          root 27665  0.0  0.0 112728   988 pts/0    S+   15:43   0:00 grep --color=auto httpd

          這個就是 apache 的所有進程 

          我們可以用  kill -9 加進程ID   如下

          kill -9 6732 kill -9 22570 kill -9 22571 kill -9 22572 kill -9 22573 kill -9 22574 kill -9 27544 kill -9 27546 kill -9 27548 kill -9 27550 kill -9 27552 kill -9 27665

          再次查看一下httpd正在運行的進程:

          (flaskApi) [root@67 flaskDemo]# ps aux |grep httpd root     27835  0.0  0.0 112724   988 pts/0    S+   15:46   0:00 grep --color=auto httpd

          全部殺完了... 殺死進程方法有很多種...我這個 只是其中的一種

           

          通過netstat確認一下,httpd已經不再占用80端口了

          (flaskApi) [root@67 flaskDemo]# netstat -tpnul

           

          另如果不想殺死進程,而想修改端口號,

          操作方法參照:centos7 ngxin啟動失?。篔ob for nginx.service failed(80端口被占用的解決辦法)

           

           

          參照文檔:

          centos殺死進程命令

           

          轉載于:https://www.cnblogs.com/kaerxifa/p/11534539.html


          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          MVP:七種深度洞察用戶需求的方法

          資深UI設計者

          不論是什么產品都需要考慮到用戶的需求,對于用戶需求進行分析,確定可行性,最后進行實現;重點要關注在產品中用戶需要的是什么,對用戶的想法進行探索;本文作者分享了關于七種深度洞察用戶需求的方法,我們一起來了解一下。


          需求分析是市場研究階段的重要活動,也是新產品開發流程中的一個重要環節,是產品經理經過深入細致的調研和分析,準確理解用戶對產品的功能、性能、可靠性等具體要求,將用戶非形式的需求表述轉化為完整的需求定義,從而確定產品必須做什么的過程;該階段是分析產品在功能上需要“實現什么”,而不是考慮如何去“實現”。

          需求分析的目標是把用戶對待開發產品提出的“要求”或“需要”進行分析與整理,確認后形成描述完整、清晰與規范的文檔,確定產品需要實現哪些功能,完成哪些工作;此外,產品的一些非功能性需求(如產品質量、款式、特色、包裝、安裝、售后等)及約束條件也是需求分析的目標。

          • “消費者不知道他們想要什么。”
          • “消費者無法很好地表達他們的需求或喜好?!?
          • “消費者對自己的具體需求很迷茫?!?

          這些都是從客戶(產品開發或者市場部的同事)或者身邊一些人(需要更多反饋的感官專家或設計者)在一整天的訪談(包括焦點小組、一對一訪談)、開放式問卷或者與消費者接觸的過程中發現的問題;這就需要我們根據調研的初步結果進行深入的“需求分析”才能得到想要的結論和應用價值。

          一、馬斯洛需求層次理論

          在組織行為學中,馬斯洛曾經在1943年發表的論文中對人類需求做出了定義,在人類動機理論中,馬斯洛提出了需求層次理論模型;這一理論可以有效地觀察人類最根本、最基礎的需求水平。

          馬斯洛認為,人類具有一些先天需求,人的需求越是低級的需求就越基本,越與動物相似;越是高級的需求就越為人類所特有。同時這些需求都是按照先后順序出現的,當一個人滿足了較低的需求之后,才能出現較高級的需求,即需求層次。

          馬斯洛理論把需要分成生理需要、安全需要、社交需要、尊重和自我實現五類,依次由較低層次到較高層次排列,如圖所示。在自我需要實現之后,還有自我超越需要,但通常不作為馬斯洛需要層次理論中必要的層次,大多數會將自我超越合并至自我實現需求當中。

          圖馬斯洛需求層次理論圖譜

          1. 第一層次:生理上的需要

          如果這些需要(除性以外)任何一項得不到滿足,人類個人的生理機能就無法正常運轉。

          換而言之,人類的生命就會因此受到威脅。從這個意義上說,生理需要是推動人們行動最首要的動力。

          馬斯洛認為,只有這些最基本的需要滿足到維持生存所必需的程度后,其他的需要才能成為新的激勵因素,而到了此時,這些已相對滿足的需要也就不再成為激勵因素了。

          2. 第二層次:安全上的需要

          馬斯洛認為,整個有機體是一個追求安全的機制,人的感受器官、效應器官、智能和其他能量主要是尋求安全的工具,甚至可以把科學和人生觀都看成是滿足安全需要的一部分;當這種需要一旦相對滿足后,也就不再成為激勵因素了。

          3. 第三層次:情感和歸屬的需要

          人人都希望得到相互的關心和照顧,感情上的需要比生理上的需要來的細致,它和一個人的生理特性、經歷、教育、宗教信仰都有關系。

          4. 第四層次:尊重的需要

          人人都希望自己有穩定的社會地位,要求個人的能力和成就得到社會的承認。尊重的需要又可分為內部尊重和外部尊重。內部尊重是指一個人希望在各種不同情境中有實力、能勝任、充滿信心、能獨立自主。

          總之,內部尊重就是人的自尊。

          外部尊重是指一個人希望有地位、有威信,受到別人的尊重、信賴和高度評價;馬斯洛認為,尊重需要得到滿足,能使人對自己充滿信心,對社會滿腔熱情,體驗到自己活著的用處價值。

          5. 第五層次:自我實現的需要

          這是最高層次的需要,它是指實現個人理想、抱負,發揮個人的能力到最大程度,達到自我實現境界的人,接受自己也接受他人,解決問題能力增強,自覺性提高,善于獨立處事,要求不受打擾地獨處,完成與自己的能力相稱的一切事情的需要;也就是說,人必須干稱職的工作,這樣才會使他們感到最大的快樂。

          馬斯洛提出,為滿足自我實現需要所采取的途徑是因人而異的。自我實現的需要是在努力實現自己的潛力,使自己越來越成為自己所期望的人物。

          馬斯洛理論把需要分成生理需要、安全需要、社交需要、尊重需要和自我實現需要五類,依次由較低層次到較高層次,從企業經營消費者滿意(CS)戰略的角度來看,每一個需求層次上的消費者對產品的要求都不一樣,即不同的產品滿足不同的需求層次。

          根據五個需要層次,可以劃分出五個消費者市場

          • 生理需求:滿足最低需求層次的市場,消費者只要求產品具有一般功能即可。
          • 安全需求:滿足對“安全”有要求的市場,消費者關注產品對身體的影響。
          • 社交需求:滿足對“交際”有要求的市場,消費者關注產品是否有助提高自己的交際形象。
          • 尊重需求:滿足對產品有與眾不同要求的市場,消費者關注產品的象征意義。
          • 自我實現:滿足對產品有自己判斷標準的市場,消費者擁有自己固定的品牌需求層次越高,消費者就越不容易被滿足。

          經濟學上,“消費者愿意支付的價格≌消費者獲得的滿意度”,也就是說,同樣的洗衣粉,滿足消費者需求層次越高,消費者能接受的產品定價也越高。

          市場的競爭,總是越低端越激烈,價格競爭顯然是將“需求層次”降到最低,消費者感覺不到其他層次的“滿意”,愿意支付的價格當然也低。

          二、KANO 模型

          KANO模型是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的有用工具,以分析用戶需求對用戶滿意的影響為基礎,體現了產品性能和用戶滿意之間的非線性關系,如圖所示。

          根據不同類型的質量特性與顧客滿意度之間的關系,狩野教授將產品服務的質量特性分為5類。

          KANO 模型(產品性能和用戶滿意之間的非線性關系)

          1. 基本型需求

          也稱為必備型需求、理所當然需求,是顧客對企業提供的產品或服務因素的基本要求;是顧客認為產品“必須有”的屬性或功能。當其特性不充足(不滿足顧客需求)時,顧客很不滿意;當其特性充足(滿足顧客需求)時,顧客也可能不會因而表現出滿意。

          對于基本型需求,即使超過了顧客的期望,但顧客充其量達到滿意,不會對此表現出更多的好感;不過只要稍有一些疏忽,未達到顧客的期望,則顧客滿意將一落千丈。

          對于顧客而言,這些需求是必須滿足的,理所當然的;對于這類需求,企業的做法應該是注重不要在這方面失分,需要企業不斷地調查和了解顧客需求,并通過合適的方法在產品中體現這些要求。

          例如,夏天家庭使用空調,如果空調正常運行,顧客不會為此而對空調質量感到滿意;反之,一旦空調出現問題,無法制冷,那么顧客對該品牌空調的滿意水平則會明顯下降,投訴、抱怨隨之而來。

          再例如,智能手機的基本型需求有語音通話質量、信號覆蓋、操作系統兼容、安全性、日常使用和性能:待機時間、速度等;試想一下,一個智能手機沒有信號,通話質量差,操作系統不兼容,被感染病毒,待機時間10分鐘就沒電,如果手機運行速度慢到接近崩潰,這些都會使用戶的不滿情緒增加;但是上述這些需求都滿足后,并不能帶來用戶滿意度的增加,因為用戶認為這些是必須要有的。

          2. 期望型需求

          也稱為意愿型需求,是指顧客的滿意狀況與需求的滿足程度成比例關系的需求,此類需求得到滿足或表現良好的話,客戶滿意度會顯著增加,企業提供的產品和服務水平超出顧客期望越多,顧客的滿意狀況越好;當此類需求得不到滿足或表現不好的話,客戶的不滿也會顯著增加。

          期望型需求沒有基本型需求那樣苛刻,要求提供的產品或服務比較優秀,但并不是“必須”的產品屬性或服務行為有些期望型需求連顧客都不太清楚,但是是他們希望得到的,也叫用戶需求的癢處;這是處于成長期的需求,客戶、競爭對手和企業自身都關注的需求,也是體現競爭能力的需求。對于這類需求,企業的做法應該是注重提高這方面的質量,要力爭超過競爭對手。

          在市場調查中,顧客談論的通常是期望型需求;質量投訴處理在我國的現狀始終不令人滿意,該服務也可以被視為期望型需求;如果企業對質量投訴處理得越圓滿,那么顧客就越滿意。

          3. 魅力型需求

          又稱興奮型需求。指不會被顧客過分期望的需求。

          對于魅力型需求,隨著滿足顧客期望程度的增加,顧客滿意度也會急劇上升,但一旦得到滿足,即使表現并不完善,顧客表現出的滿意狀況則也是非常高的;反之,即使在期望不滿足時,顧客也不會因而表現出明顯的不滿意。

          當顧客對一些產品或服務沒有表達出明確的需求時,求企業提供給顧客一些完全出乎意料的產品屬性或服務行為,使顧客產生驚喜,顧客就會表現出非常滿意,從而提高顧客的忠誠度;這類需求往往是代表顧客的潛在需求,企業的做法就是去尋找發掘這樣的需求,領先對手。

          例如,一些著名品牌的企業能夠定時進行產品的質量跟蹤和回訪,發布最新的產品信息和促銷內容,并為顧客提供最便捷的購物方式。對此,即使另一些企業未提供這些服務,顧客也不會由此表現出不滿意。

          4. 無差異型需求

          不論提供與否,對用戶體驗無影響;是質量中既不好也不壞的方面,它們不會導致顧客滿意或不滿意。例如:航空公司為乘客提供的沒有實用價值的贈品。

          5. 反向型需求

          又稱逆向型需求,指引起強烈不滿的質量特性和導致低水平滿意的質量特性,因為并非所有的消費者都有相似的喜好。

          許多用戶根本都沒有此需求,提供后用戶滿意度反而會下降,而且提供的程度與用戶滿意程度成反比;例如:一些顧客喜歡高科技產品而另一些人更喜歡普通產品,過多的額外功能會引起顧客不滿。

          前三種需求根據績效指標分類就是基本因素、績效因素和激勵因素。在實際操作中,企業首先要全力以赴地滿足顧客的基本型需求,保證顧客提出的問題得到認真的解決,重視顧客認為企業有義務做到的事情,盡量為顧客提供方便,以實現顧客最基本的需求滿足。

          然后,企業應盡力去滿足顧客的期望型需求,這是質量的競爭性因素;提供顧客喜愛的額外服務或產品功能,使其產品和服務優于競爭對手并有所不同,引導顧客加強對本企業的良好印象,使顧客達到滿意。

          最后爭取實現顧客的興奮型需求,為企業建立最忠實的客戶群。

          三、因子分析

          因子分析是指研究從變量群中提取共性因子的統計技術。

          最早由英國心理學家C.E.斯皮爾曼提出。他發現學生的各科成績之間存在著一定的相關性,一科成績好的學生,往往其他各科成績也比較好,從而推想是否存在某些潛在的共性因子(某些一般智力條件)[張樂飛1] 影響著學生的學習成績。

          因子分析可在許多變量中找出隱藏的具有代表性的因子,將相同本質的變量歸入一個因子,可減少變量的數目,還可檢驗變量間關系的假設。

          因子分析是社會研究的一種有力工具,但不能肯定地說一項研究中含有幾個因子,當研究中選擇的變量變化時,因子的數量也要變化;此外對每個因子實際含意的解釋也不是絕對的。在市場調研中,研究人員關心的是一些研究指標的集成或者組合,這些概念通常是通過等級評分問題來測量的,如利用李克特量表取得的變量。

          每一個指標的集合(或一組相關聯的指標)就是一個因子,指標概念等級得分就是因子得分。

          因子分析方法的主要應用有兩種:其一,減少變量的數量;其二,找出變量之間的結構關系。

          在產品開發中,因子分析能夠用于關鍵變量的優先級排序和分組,比如:產品屬性之間的關系和產品屬性對產品偏好的影響。在實際應用中,通過因子得分可以得出不同因子的重要性指標,而管理者則可根據這些指標的重要性來決定首先要解決的市場問題或產品問題。

          四、聚類分析

          聚類分析是一種探索性的分析,在分類的過程中,人們不必事先給出一個分類的標準,聚類分析能夠從樣本數據出發,自動進行分類。

          聚類分析所使用方法的不同,常常會得到不同的結論。不同研究者對于同一組數據進行聚類分析,所得到的聚類數未必一致。

          從實際應用的角度看,聚類分析是數據挖掘的主要任務之一;而且聚類能夠作為一個獨立的工具獲得數據的分布狀況,觀察每一簇數據的特征,集中對特定的聚簇集合作進一步地分析。聚類分析還可以作為其他算法(如分類和定性歸納算法)的預處理步驟。

          聚類分析的一個重要用途就是針對目標群體進行多指標的群體劃分,類似這種目標群體的分類就是精細化經營,個性化運營的基礎和核心,只有進行了正確的分類,才可以有效進行個性化和精細化的運營,服務及產品支持等。

          常見業務應用場景如下:

          1. 目標用戶的群體分類

          通過對特定運營目的和商業目的所挑選出的指標變量進行聚類分析,把目標群體劃分成幾個具有明顯特征區別的細分群體,從而可以在運營活動中為這些細分群體采取精細化,個性化的運營和服務,最終提升運營的效率和商業效果(如把付費用戶按照幾個特定維度,如利潤貢獻,用戶年齡,續費次數等聚類分析后得到不同特征的群體)。

          2. 不同產品的價值組合

          企業可以按照不同的商業目的,并依照特定的指標標量來為眾多的產品種類進行聚類分析,把企業的產品體系進一步細分成具有不同價值,不同目的的多維度的產品組合,并且在此基礎分別制定和相應的開發計劃,運營計劃和服務規劃(如哪些產品是明星類產品,那些產品是瘦狗類產品)。

          3. 數據挖掘、分析、應用

          聚類分析是挖掘電子商務網站數據價值的重要方法之一,通過分組聚類出具有相似瀏覽行為的客戶,并分析客戶的共同特征,可以更好的幫助電子商務的用戶了解自己的客戶,向客戶提供更合適的服務(如某B2C電商平臺上,根據用戶的搜索、瀏覽、購買記錄通過大數據分析,通過第三方平臺向客戶精準推送產品)。

          聚類分析是細分市場的有效工具,同時也可用于研究消費者行為,尋找新的潛在市場、選擇實驗的市場,并作為多元分析的預處理。

          五、多維度尺度法

          多維尺度法是一種將多維空間的研究對象(樣本或變量)簡化到低維空間進行定位、分析和歸類,同時又保留對象間原始關系的數據分析方法;其特點是將消費者對產品的感覺偏好,以點的形式反映在多維空間上;而對不同產品的感覺或偏好的差異程度,則是通過點與點間的距離體現的,我們稱這種產品或項目的空間定位點圖為空間圖,空間軸代表著消費者得以形成對產品的感覺或偏好的各種因素或變量。

          在分析消費者對產品功能的需求度時,首選選擇研究對象,如列出某個產品的所有產品功能;然后從目標市場中抽取一個樣本人群(通常30-50人),讓他們對產品功能的需求度打分;最后采用多維度分析獲得一張代表了產品功能需求度關系的可視化圖。

          可視化圖中的維度代表了消費者對產品功能需求依賴的關鍵要素,為方便起見通常選擇2-3個維度。投保人購買保險產品時所需的第三方互聯網工具產品功能在生命周期和需求頻率上的多維度分析如圖所示;通過多維尺度分析幫產品經理區分功能優先級,做出產品決策。

          投保人互聯網工具產品應用多維度分析

          多維尺度分析優點是很明顯的。研究者可以利用得到的位置結構圖將研究對象進行分類,還可以對隱藏在數據背后的空間維度做出相應的判斷和解釋。

          多維度分析通過把所研究對象的數量關系轉化為直觀圖形,達到直觀展現研究對象的目的;多維尺度分析的缺點是分析結果不是唯一的,結果可以在空間中旋轉和平移,這為分析者對結果的解釋制造了難度。

          六、聯合分析

          聯合分析法,又稱結合分析法,是對結合效應的評價,從而有效地解決了傳統調查方法中需要調研對象獨立評價屬性的問題。

          聯合分析有三種主要形式,包括權衡矩陣法、兩兩比較法和全輪廓法,其中又以全輪廓法最為常用;該方法提供給研究的參與者一系列的產品描述,參與者被要求瀏覽所有的描述,做出一系列的評價,對調研結果進行數學方法分析后,就可以導出該類產品的各屬性的效用值。

          對于市場研究領域,在聯合分析之前的所有方法幾乎都會使用重要性比率尺度來度量產品屬性的重要性水平,即都會直接向消費者提問一個產品中他們最看重的屬性。

          這種方法有幾個嚴重的缺點:首先,調研的經驗表明,如果不限制條件的話,消費者傾向于認為每個屬性幾乎都是同等重要的;其次,消費決策很大程度上依賴的是整體的判斷。當消費者被要求分離各種屬性并且對各屬性進行量化評價并且描述某個屬性水平的高低將驅使其購買一個產品而不是另一個產品時,即使是最老練的消費者也將感到無所適從。

          在聯合分析中產品被描述成為輪廓,每一個輪廓由能夠描述產品重要特征的屬性和賦予每一屬性的不同水平的組合構成。

          消費者在實際購買時并不是基于產品某一屬性而是綜合考慮產品各個屬性及屬性水平從而做出購買決策的。因此消費者對某一產品輪廓的評價可以分解成構成這個輪廓多個屬性水平的評價以及不同屬性在決策時所占的權重。

          在聯合分析中用分值也叫做效用來描述消費者對某一屬性水平的偏好,聯合分析能夠較好地模擬消費者購買的實際過程,從而客觀、真實地測量消費者對某一產品的偏好及產品不同屬性在購買過程中的重要性。

          以QQ會員等級為例,如圖向用戶展示屬性組合以及用戶需求等級。在本例中,有8個不同屬性,每種屬性對應9種不同的屬性水平,由此構成的屬性組合可以滿足不同的QQ用戶的需求。

          聯合分析(騰訊QQ群產品會員等級劃分)

          聯合分析是對人們購買決策的一種現實模擬。因為在實際的抉擇過程中,由于價格等原因,人們要對產品的多個特征進行綜合考慮,往往要在滿足一些要求的前提下,犧牲部分其他特性,是一種對特征的權衡與折衷。

          通過聯合分析,我們可以模擬出人們的抉擇行為,可以預測不同類型的人群抉擇的結果;因此,通過聯合分析,我們可以了解消費者對產品各特征的重視程度,并利用這些信息開發出具有競爭力的產品。

          七、李克特量表

          李克特量表是屬評分加總式量表最常用的一種,屬同一構念的這些項目是用加總方式來計分,單獨或個別項目是無意義的,它是由美國社會心理學家李克特于1932年在原有的總加量表基礎上改進而成的。

          李克特量是目前調查研究中使用最廣泛的量表,當受測者回答此類問卷的項目時,他們具體的指出自己對該項陳述的認同程度;該量表由一組陳述組成,每一陳述有“非常同意”、“同意”、“不一定”、“不同意”、“非常不同意”五種回答,分別記為5、4、3、2、1,每個被調查者的態度總分就是他對各道題的回答所得分數的加總,這一總分可說明他的態度強弱或他在這一量表上的不同狀態。

          李克特量表應用步驟“

          1)收集大量(50~100)與測量的概念相關的陳述語句。

          2)有研究人員根據測量的概念將每個測量的項目劃分為“有利”或“不利”兩類,一般測量的項目中有利的或不利的項目都應有一定的數量。

          3)選擇部分受測者對全部項目進行預先測試,要求受測者指出每個項目是有利的或不利的,并在下面的方向-強度描述語中進行選擇,一般采用所謂“五點”量表:

          • 非常同意
          • 同意
          • 無所謂(不確定)
          • 不同意
          • 非常不同意

          4)對每個回答給一個分數,如從非常同意到非常不同意的有利項目分別為5、4、3、2、1分,對不利項目的分數就為1、2、3、4、5。

          5)根據受測者的各個項目的分數計算代數和,得到個人態度總得分,并依據總分多少將受測者劃分為高分組和低分組。

          6)選出若干條在高分組和低分組之間有較大區分能力的項目,構成一個李克特量表;如可以計算每個項目在高分組和低分組中的平均得分,選擇那些在高分組平均得分較高并且在低分組平均得分較低的項目。

          我通常會在產品的早期創建一張范圍矩陣表,用來列出所有討論過功能和內容。這樣一個范圍工具就出現了,它可以用來支持人們討論整體的優先級別,以及每一個功能的工作量,然后決定哪些功能應該納入范圍之內,而哪些應該排除在外。

          在分析每一個功能的重要性的時候,把人物角色加入這個工具中,就能讓這些用戶始終停留在每一個人的腦海中,可以大大地幫助你在決定項目范圍時,把人物角色變成其中一個積極的部分,如圖所示。

          李克特5點范圍矩陣量表(功能需求度轉化)

          李克特量表的構造比較簡單而且易于操作,因此在市場研究實務中應用非常廣泛。

          在實地調查時,研究者通常給受測者一個“回答范圍”卡,請他從中挑選一個答案;需要指出的是,目前在商業調查中很少按照上面給出的步驟來制作李克特量表,通常由產品經理和研究人員共同研究確定。

          文章來源:人人都是產品經理  作者:長乘

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務





          登錄頁需要注意的設計細節和邏輯

          資深UI設計者

          確保用戶成功且無壓力的登錄體驗需要我們不斷地思考。




          大家好,我是Clippp。今天為大家分享的文章是「登錄頁」設計。幾乎所有的登錄頁看起來都大同小異,通過輸入賬號和密碼就能夠進入,但仔細思考會發現,每個登錄頁都有差異化的點,而這些點正是產品無一物二的地方。

          1、什么是登錄體驗?

          登錄體驗是指用戶通過入口進入應用、網站或服務,建立自己的身份。

          登錄流程通常由主登錄流程和恢復流程組成,其中主登錄流程包括填寫用戶名、手機號、密碼等,恢復流程包括忘記密碼、重置密碼、其他登錄方式等。登錄體驗的目標是確保用戶成功登錄帳戶。

          2、設計熟悉的登錄流程

          使用簡潔、常用的頁面布局和文字,有助于用戶輕松執行熟悉的操作。保持設計簡單也有助于將體驗輕松擴展到不同設備和屏幕尺寸。

          ▲ Pinterest采用了居中對齊的重疊式登錄頁設計,用醒目的紅色按鈕來突出登錄動作,還支持Google和Facebook作為其他登錄方式。

          登錄頁是強調品牌的首要接觸點。登錄操作最好于中心位置,頁面上的其他元素應謹慎增加,避免注意力從登錄任務上移開。

          設計思考:

          用戶花在登錄頁上的時間越少越好,要讓用戶盡快發現產品中的優點和價值!

          3、專注設計

          登錄(或恢復)操作應引起用戶的全部注意力:

          • 最好將登錄頁表單放在頁面中心位置;

          • 不需要復雜或冗長的文字解釋,例如可以利用簡單的“輸入密碼”來提示用戶完成操作;

          • 要求用戶一次只做一件重要的事情,例如將找回密碼這種復雜的流程分解為多個步驟進行。

          ▲ Facebook保留用戶的登錄信息,并將恢復流程分為幾個邏輯步驟。

          ▲ 亞馬遜將輔助恢復選項放在“更多幫助”中,這有助于使主要操作保持重點。

          設計思考:

          使用卡片式布局;

          將操作分為主要動作和次要動作;

          使用尺寸大而突出的登錄按鈕;

          盡量減少次要操作的次數,以避免使頁面出現混亂。


          4、給出明確反饋并在操作失敗時提供幫助

          在登錄過程的每個階段,用戶都可能會失敗。輸入錯誤的郵箱,忘記密碼或網絡問題等,所有這些問題都可能導致登錄意圖急劇下降。

          因此清晰及時的反饋設計對用戶來說很重要。

          ▲ 信息輸入錯誤時會提示錯誤具體的原因。

          ▲ 密碼輸入有誤時,Facebook會在下方增加“使用Google登錄”選項。

          設計思考:

          鼓勵用戶嘗試合適的替代方案;

          登錄失敗后,將用戶導航到單獨頁面并組織其他登錄方法;

          展示最有效的登錄方法,并在發生問題時及時對用戶做出反饋。

          5、多種登錄方式提供靈活性

          除了輸入賬號密碼這種登錄方式,最好提供一種或兩種附加的登錄方式以便用戶選擇,同時防止忘記密碼造成無法登錄的情況。

          添加過多的登錄方式會使頁面混亂,降低登錄意圖,附加選項應該限制為2或3種方式。

          ▲ Medium登錄表單的設計盡管很清晰,但過多的登錄方式會阻礙用戶的選擇和判斷。

          ▲ Airbnb登錄頁能看到大量的輔助登錄方式,過多的選項可能會導致用戶的認知負荷。

          設計思考:

          當前無密碼登錄正在迅速普及。在很多移動App中,基于手機號的身份驗證已成為常態,指紋和FaceID也出現在許多地方,從而實現了無縫和安全的身份驗證流程。

          找到產品最適合的登錄方式,并將其作為主要選擇能有效提升效率!

          6、登錄意味著信任

          登錄涉及用戶輸入敏感的個人數據,例如手機號、郵箱、密碼等,用戶愿意輸入信息意味著他們信任這個平臺或產品。

          雖然減少與用戶的摩擦很重要,但有時網站也會提供額外的身份驗證來確保用戶信息的安全。

          ▲ B站利用文字驗證方式來增強用戶帳戶的安全性。

          設計思考:

          登錄表單應該代表品牌的形象,任何視覺上的變化都必須慢慢進行,因為完全改變視覺設計可能會導致缺乏信任。

          7、確定用戶類型

          登錄意圖是一種體驗,在這種體驗中用戶角色和類型可以無所不包。

          可以嘗試以下方式來定義用戶的范圍以便更清楚的了解用戶:

          登錄渠道:與PM合作找出在登錄流程中用戶交互和退出的關鍵階段。

          登錄入口:用戶是通過郵箱、搜索引擎還是通過應用跳轉到登錄頁?

          常用設備:手機、瀏覽器等設備可以為用戶帶來個性化的體驗。

          用戶群組:利用年齡或地理位置等方式也能進行分離用戶群主的劃分。

          8、登錄頁設計實例分析 

          通過分析具有代表性的登錄頁設計來展示登陸頁的多種設計表達。

          ▲ Google采用多階段的登錄方式,郵箱和密碼分兩步進行輸入。這種格式對谷歌來說有一些安全優勢,也可以在下一步為用戶提供個性化的選擇。

          ▲ Uber的登錄頁采用簡單的樣式,注重使用體驗,引導用戶輸入手機號來進行下一步。

          ▲ Facebook利用右對齊的登錄表單很好地集中注意力,左邊的空間被用來展示品牌的信息和形象。

          ▲ 亞馬遜的登錄頁從視覺設計上看有些陳舊,但卻是管理用戶注意力的一個很好的例子。黃色的“繼續”按鈕和簡潔的頁面使登錄看起來簡單而快速。

          ▲ Figma的登錄頁位于畫面中心,頂部首先展示的是以Google登錄,這可能是Figma首選和推廣的登錄形式,頁面整體的設計利用線框組成,非常簡潔高效。



          文章來源:展開  作者:Clippp

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務






          熱門的手機用戶輸入設計模式

          ui設計分享達人

          對于任何手機應用程序,如果沒有來自用戶的一些初始和正在進行的輸入,就不會發生任何事情。因此,手機產品設計師、開發人員和產品經理必須了解允許用戶這樣做的最佳方式。

          雖然手機應用程序以及使用它們的用戶通常是獨一無二的,但是有許多常見的模式(新模式和舊模式)被用來解決這個特定的問題。


          用戶輸入設計的6個目標


          在我們深入研究模式之前,了解用戶輸入設計的六個主要目標是很重要的:

          1. 選擇合適的輸入和資料登錄方法

          2. 減少輸入量

          3. 設計有吸引力的數據輸入屏幕

          4. 使用驗證檢查來減少輸入錯誤

          5. 設計所需的輸入文檔

          6. 制定有效的輸入控制


          模式的概述


          在記住以上設計目標的前提下,下面是我們在將本文中詳細介紹的設計模式的概述,在我們的電子書《2014年手機用戶界面設計模式》中有更詳細的介紹:

          1.智能鍵盤
          2.默認值&自動完成
          3.立即沉浸(或“惰性注冊”)
          4.操作欄
          5.社交賬號登錄
          6.巨大按鈕
          7.滑動操作
          8.通知
          9.顯性控件
          10.可擴展輸入
          11.撤銷


          1.智能鍵盤


          Facebook記事本,Android聯系人


          問題
          用戶希望快速輸入信息。


          解決方案
          當用戶點擊應用程序中允許輸入信息的部分時,給他們與輸入數據相關的鍵盤。這使他們不必在字母數字屏幕之間尋找正確的按鈕,或者多走一步來訪問鍵盤。這不僅方便了用戶,而且還指示了需要從用戶那里得到什么類型的輸入。手機平臺允許相應地標記文本字段,這允許在哪些按鈕顯示在更顯著位置方面有一定的靈活性。


          例如,在地址簿或撥號器中輸入電話號碼時,用戶不需要完整的鍵盤。當他們點擊這些字段時,數字小鍵盤就會彈出,而不是整個鍵盤,這樣就減少了不必要的按鈕,簡化了操作過程。類似地,點擊瀏覽器中的URL欄會彈出一個稍微修改過的鍵盤,其中“/”和“。com”按鈕顯示在空格鍵旁邊,而不是符號鍵后面。通過連接到系統提供的這些智能鍵盤類型,你的UI可以根據用戶當前嘗試的操作進行調整。


          2.默認值&自動完成

          Skype, Flightboard


          問題
          用戶希望快速完成操作。


          解決方案
          通過為用戶提供預先填充的默認值或基于先前輸入的數據的提示,預測頻繁選擇的項并使用戶更容易地進行數據輸入。這可以與自動完成功能相匹配,比如在谷歌Play Store搜索中,通過加速來顯著改善用戶體驗。這種模式在標準化用戶輸入和在問題發生之前預測問題方面特別有用。例如,Skype會自動為輸入的電話號碼匹配國家代碼。從用戶的角度來看,這是有意義的,因為他們不習慣定期輸入這些信息,但在這種情況下,這種匹配很重要,因為Skype是一個國際電話應用程序。


          另一種實現方法是保存用戶輸入的最后一項,并在用戶再次輸入或搜索時顯示這些最近使用過的項。例如,Flightboard在搜索框下面列出了以前使用過的位置,以避免用戶再次輸入。大多數地圖或導航應用程序也采用這種模式,在搜索方向時自動輸入用戶當前位置,為用戶節省幾次點擊,因為這是最常見的情況。


          3.立即沉浸(或“惰性注冊”)

          Wunderlist


          問題
          用戶希望在注冊之前先嘗試一下。


          解決方案
          越來越多的應用程序允許用戶在任何事情發生之前——甚至是注冊或登錄之前——立即沉浸在應用程序中。


          記住,他們一次只能做一件事,而且測試每個新產品的時間有限。隨著應用程序的日益專業化,在扶持它們之前找到高質量的用戶或客戶越來越重要——他們可能會討厭你的產品或很快意識到它不是他們想要的。向用戶詢問注冊賬戶所需的信息可能是一件很困難的事情,而且會降低甚至是適合的訪問者的注冊率。在積極的方面,通過讓他們立即體驗你的產品,他們更有可能被吸引,因為他們能夠在第一次體驗時深入探索應用程序。這比我們接下來討論的onboarding walkthrough UI模式更好,因為它向用戶展示而非告訴他們應用程序如何工作。


          對于Carousel或Duolingo等依賴用戶數據來運行的應用程序來說,允許延遲注冊是沒有意義的,但Wunderlist或Houzz等應用程序可以允許用戶在要求他們確認身份之前進入并使用該應用程序。通常情況下,注冊會帶來一些額外的好處,比如在Wunderlist中進行跨設備同步,或者在Houzz中創建一本想法書,這會讓注冊變得更有吸引力。延遲注冊并不總是一個好主意,但是選擇“注冊前試用”可以很好地提高你的應用程序的參與度。


          4.操作欄

          Facebook Paper, Behance


          問題
          用戶希望快速訪問常用的操作。


          解決方案
          從應用程序的操作欄(或iOS術語中的“工具欄”)提供對重要操作的快速訪問。雖然導航條主導了web和早期的手機應用程序設計, 但其他模式的使用,如折疊、滑出式工具欄和側邊欄、指向所有內容的鏈接、按鈕轉換、垂直的和基于內容的導航,產生了更簡單的應用程序視圖,用戶可以專注于一級和二級操作,而不是二級導航。常見的操作有:在應用程序中搜索、共享和創建新內容。這個存留的菜單可以幫助用戶熟悉UI,還可以通過專注于與用戶相關的重要操作清除一些混亂。


          5.社交賬號登錄

          undefined

          Beats Music, Flipboard


          問題
          用戶需要一種更簡單的注冊和登錄方式。


          解決方案
          整合社交賬號登錄方法,允許用戶通過現有賬戶登錄。這意味著他們少了一個需要擔心的用戶名/密碼組合,同時,你也不必擔心密碼的安全性。Facebook、Twitter和谷歌是主要的OAuth登錄提供商,根據平臺和目標受眾的不同,你可以在你的應用程序中提供所有這些或其中之一,而不是讓用戶建立一個他們可能會也可能不會在未來使用的單獨的帳戶。使用這個注冊和登錄模式也可以為你提供一些基本的關于用戶的數據(當他們使用應用程序時,會自動填充數據), 同時,通過不強迫用戶在剛下載的陌生應用程序中輸入他們的詳細信息,讓他們更加舒適。這個簡單的特性可以在很大程度上改進你的UX,因此這種模式正在成為一種期望。


          6.巨大按鈕

          Tinder, Shazam


          問題
          用戶希望立即知道他們可以采取哪些操作。


          解決方案
          理想的觸屏點擊目標大小可能是72 px,但是一些應用程序,像Tinder,也會給你巨大的按鈕讓你確切地知道該做什么, 無論你在什么位置,無論你在做什么,你都能很快完成操作——很難錯過這些巨大的按鈕,即使你沒在仔細看。這在更簡單的應用程序中尤其有價值,因為在這些應用程序中,用戶需要執行的操作非常有限,因此更有理由讓他們在各種情境中更容易地執行這些操作。例如,Shazam是用來看電視或聽音樂的,它實際上只做一件事。對于試圖在這種分心狀態下進行多任務處理的用戶來說,巨大的按鈕是一個巨大的改進。


          7.滑動操作

          Carousel


          問題
          用戶希望關注特定的內容。


          解決方案
          允許內容被滑動或移動。這為用戶提供了一種非常直觀的方式來處理屏幕上的信息。例如,谷歌中的“卡片”現在可以在你不需要的時候被滑走,以清理雜物;類似地,Tinder中的配置文件可以向左或向右滑動,以表示積極或消極的響應。這個模式與我們在導航模式中討論的滑動視圖不同。在這里,滑動手勢被用于一項操作,而不僅僅是瀏覽。有些應用程序結合了兩種滑動模式,比如Carousel,它可以讓你通過將照片滑動到一邊來瀏覽多張照片,也可以通過向上或向下滑動來分享或隱藏照片。郵箱推廣了電子郵件客戶端的左右滑動操作,允許你分別通過向右或向左滑動將郵件標記為已讀或安排為待處理。Secret用讓你發現新菜單的方式來讓你發現新動作。向左滑動一個secret代表你喜歡它。


          8.通知

          LinkedIn, Facebook


          問題
          用戶希望了解他們應該瀏覽的新活動或操作。


          解決方案
          通過標記新內容來突出最近的活動。這個模式有幾種實現方式。例如,在標簽上放置一個計數徽章是由iOS推廣開來的,但現在這也可以在許多其他應用程序中看到,如LinkedIn、Facebook或Quora。Twitter在通知按鈕上也這樣做,但它在時間軸圖標的頂部還有一個小點,以更微妙的方式指示新的活動。另一種顯示通知的方式是在應用程序中使用一個向下拉的橫幅來顯示新活動。Facebook應用程序也能做到這一點,當新聞推送中出現新條目時,它會彈出一個小窗口。


          9.顯性控件

          Secret


          問題
          用戶希望快速訪問那些二級的或僅與應用程序中的特定部分或內容相關的控件。


          解決方案
          清理雜物,讓用戶只在需要時才發現特定的操作。這些看不見的控件可以通過任何手勢來訪問——滑動、輕擊、雙擊、長按等等(我們在手勢模式中討論過)。這使你能夠將這些操作保留在屏幕之外,從而節省一些寶貴的空間。例如,Secret使用手勢而不是可視控件。向右滑動,就會出現一個動作菜單,這是我們前面介紹過的折疊模式的簡化版。在創建內容時,用戶可以在背景上水平滑動或垂直滑動手指來改變背景的顏色和圖案,或者在使用圖片時,可以改變圖片的亮度、飽和度或模糊度。沒有其他控件允許你這樣做——也不應該有其他控件。這種UI設計模式非常直觀、清晰,你一定會看到更多這種類型的交互。Pinterest是另一個使用手勢隱藏動作按鈕的應用程序。長時間按下一個圖像,就會出現一個按鈕,用戶可以通過將彈出控件拖動到該按鈕上來對其進行固定或評論。


          Uber是這種設計模式的另一種實現方式。Uber還可以讓你在預訂和查看車費估算之間進行切換,只要你選擇了你想要的乘車類型,就可以通過點擊滑塊按鈕來查看車費估算。這是一個簡單而又重要的UI設計模式,每當我在做五件事的同時還想搭個便車,同時還要確保Uber不會用峰時價格來騙我的時候,它都會讓我微笑。Snapchat和Facebook Messenger允許你在需要的時候通過滑走所有朋友的賬戶來訪問這些功能。


          10.可擴展輸入

          YouTube


          問題
          用戶希望關注內容,而不是犧牲屏幕空間給控件。


          解決方案
          設計當用戶點擊時會展開的控件。這使得大多數控件在用戶需要它們之前都不會出現。例如,YouTube和Facebook通過將搜索欄隱藏在一個圖標后面來節省屏幕空間,當用戶點擊這個圖標時,它就會展開成一個搜索欄。


          11.撤銷

          Gmail, Chrome


          問題
          用戶希望在沒有中斷(例如:確認)的情況下快速地執行操作,但是可以選擇恢復意外操作。


          解決方案
          為用戶提供一個簡單的方法來撤銷他們的操作,而不只是要求他們事先確認。在某些情況下,某個操作可能會導致不方便或數據丟失,例如刪除電子郵件或編輯一些文本。用戶可能因為不知道會發生什么而完成了一個動作;一個寬容的用戶界面可以讓他們體驗到更多的參與感和友好。對于高級用戶來說,撤銷功能也很強大,他們會喜歡在整個過程中不用UI反復詢問他們是否確定要繼續操作,就能更好地控制局面。在解釋將要發生的事情時,確認彈出窗口可能很有用,但是用戶可能直到看到操作的結果才會理解其含義。在這種情況下,最好是讓開,同時提供一個安全網絡,以防出現錯誤。


          獲取用戶的輸入
          時刻記錄你應該從用戶那里獲得輸入的位置,他們是否曾經查看過這些輸入區域,他們使用這些輸入控件的頻率,他們從哪里來,又從哪里進入應用程序(即用戶流),等等。不斷地重新安排、重新排序、調整大小和調整這些控件,直到你獲得更多所需的操作。當然,當用戶能夠提供輸入時,要深入考慮他們實際上是如何使用你的移動應用程序的——確保你在設計應用程序時沒有遺漏什么明顯的東西。

          文章來源:站酷  作者:馬克筆設計留學

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          Web產品的適配設計選型

          ui設計分享達人

          開篇


          • 寬度單位我是用百分比還是px?還是rem?區別是什么?

          • 什么是屏幕尺寸、屏幕分辨率、屏幕像素密度、設備像素、css像素?瀏覽器窗口大小和設備大小和分辨率大小區是什么區別?

          • 什么是響應式網站,自適應又是什么?兩者有何區別和聯系?

          • 百分比寬度布局和流式布局和前者的關系是什么?

          • 既然響應式這么流行,為何淘寶、京東等沒有去做,而是單獨開發了一個移動端版?這里面有那些坑需要避開?



          歷史長廊


          在早期,硬件設備落后,網頁使用的是絕對靜態布局為主,絕對固定寬度的布局被稱為是靜態布局(StaticLayout),也有叫固定布局(Fixed Layout)。


          后隨時代變遷,技術發展。因瀏覽器的增多,開發者們忙于兼容各種瀏覽器。在這個期間,實際已經有了針對各設備適配的解決方案,只是未成為主流,這種新布局方式叫自適應布局(Adaptive Web Design,簡稱AWD)。

          在當時,大多指的就是寬度自適應布局。在這種新思想下,又出現了兩派的具體解決方案:百分比寬度布局和流體式布局(Fluid Layout)。


          在當時,大家都還沒有響應式布局的概念,但此時出現了一個新的詞--漸進增強。漸進增強出現后,另一個詞優雅降級也隨之出現了。這里只是舉個典型的例子:gmail和qqmail。這兩個都是百分比寬度布局,都屬于自適應布局,但有區別。


          qqmail就是css hack的完美體現,你用任何一個瀏覽器,幾乎可以看到同一個樣子的郵箱,為的是用戶體驗統一。gmail則使用了漸進增強,你的瀏覽器越新越強,你看到的效果就越好,為的是用戶體驗增強。再后來,Google發布了Android,移動互聯網爆發,html5標準發布。


          互聯網大戰從PC打到了手機。手機雖然屏幕變小了,但是卻提供了更豐富的功能,用戶要求不斷提高,網站更加看重的是用戶體驗了,所以,谷歌式的漸進增強被廣泛認可,結合自適應的思想,出現了響應式布局 (Responsive Web Design)的概念——2010年由Ethan Marcotte提出。


          描述響應式界面最著名的一句話就是“Content is like water”——無論用戶正在使用筆記本還是iPad,我們的頁面都應該能夠自動切換分辨率、圖片尺寸及相關腳本功能等,以適應不同設備。



          現如今,為何需要考慮多設備的兼顧呢,依然是因為時代發展與生活方式的變遷:

          • 即便是PC或Mac用戶,有查顯示只有一半的人會將瀏覽器全屏顯示,而剩下的一般人使用多大的瀏覽器,很難預知;

          • 臺式機、投影、電視、筆記本、手機、平板、手表、VR……智能設備正在不斷增加,“主流設備”的概念正在消失;

          • 屏幕分辨率正飛速發展,同一張圖片在不同設備上看起來,大小可能天差地別。

            結合自身產品用戶訪問瀏覽器分辨率

          • 鼠標、觸屏、筆、攝像頭手勢……不可預期的操控方式正在不斷出現。

          因此我們需要在了解基本布局方式的特征下,選擇適合自身產品的布局實現方式。


          布局方式對比


          靜態式、自適應、流體式、響應式布局,A+R混合布局的特點對比如下


          靜態式布局:

          窗口縮小后內容被遮擋時,拖動滾動條顯示布局。不管在哪種設備,哪種瀏覽器上瀏覽都是一個樣。移動設備上則顯示太小或不全。



          自適應布局:

          用自適應技術(Adaptive)我們可以開發和提供不同的布局來為類似純觸屏或者混合觸屏設備這樣的一類具體場景提供最好的體驗。


          分別為不同的屏幕分辨率設備設計不同的樣式布局,相當于多個靜態布局組成的一個系列合集,每個靜態布局對應一個屏幕分辨率范圍,頁面通過百分比自動適配設備屏幕分辨率和可視窗口大小,當可視窗口改變時,不會出現橫向滾動條,UI,圖片,文字會自動縮放,元素內容、布局、交互方式基本不變。



          彈性布局:

          以百分比作為頁面的基本單位,可以適應一定范圍內所有尺寸的設備屏幕及瀏覽器寬度,并能完美利用有效空間展現最佳效果。



          流體式布局:

          屬于自適應的一個子集,也是通過百分比自動適配設備屏幕分辨率和可視窗口大小,不同于百分比自適應的是隨著窗口大小的改變,頁面的布局會發生小的變化,可以進行適配調整,這個正好與自適應相補。



          響應式布局:

          如果從廣義上講,響應式布局實際上就是更好、更機智、更靈活的去實現自適應,他們都算是一種彈性布局。再通俗點講響應式重在于「響應」它會隨著設備屬性(如寬高)的變化。


          頁面的設計和開發應當根據用戶行為以及設備環境(系統平臺、屏幕尺寸、屏幕定向等)進行相應的響應和調整。具體的實踐方式由多方面組成,包括彈性網格和刪格、布局、圖片、css media query的使用等。


          狹義上講,響應式網頁設計指的是一個網站能夠兼容多個終端——而不是為每個終端做一個特定的版本。



          A+R混合模型布局

          R和A上的區別

          當響應式設計在基于預定義斷點之上用CSS或者JS調整布局和內容。調整方法提供基于用戶代理和設備類型的預結構化模版。


          他們之間主要的區別是DOM結構,當采用響應式思維開發時,HTML代碼在各種情況下都會一樣(除非你用JS移除某些DOM節點),而在自適應開發中我們可能會有不一樣的代碼結構和體驗。


          R采用流體+斷點,在斷點之間,頁面依然會隨窗口大小自動縮放(通過fluid grid),直到遇到斷點改變界面樣式布局甚至內容。R一般來說需要在網頁設計初期就開始(通常采用mobile first策略),所以舊的網站要做RWD很可能要完全重建。


          A只在針對幾種分辨率(如320,480,760,960,1200,1600px)進行優化,在斷點之間的自動過渡比較少。而A則采用保留現有桌面網站(desktop version)而對于更小的分辨率做針對性的優化(適應),減小重構的成本。



          兩種設計思維都是有效的,需衡量在項目中有多少組件、復雜性如何以及是否存在一種體驗是適合所有用戶的。開發web應用時經常會用到響應式設計,例如通過自適應開發來構建定制化體驗。


          兩種方法各有利弊,但是如果同時使用它們到底會得到什么呢?A+R模型結合了基于單個主要臨界點的自適應和響應式方法。


          混合式布局就是為不同終端設備的屏幕分辨率定義布局(適配各種尺寸的PC、手機、穿戴設備等等),在每個布局中,頁面元素隨著窗口調整而自動適配,混合了百分比、像素為基本單位的組合方式??梢园鸦旌鲜讲季挚醋魇菑椥圆季?、自適應布局的融合。



          自適應布局、彈性布局、混合布局都是響應式布局方式的一種。其中自適應布局的實現成本最低,但拓展性比較差;而彈性布局與混合布局效果都是比較理想的響應式布局實現方式。


          很多時候,單一方式的布局響應無法滿足理想效果,需要結合多種組合方式,但原則上盡可能是保持簡單輕巧,而且同一斷點內(發生布局改變的臨界點稱之為斷點,后面內容會講到)保持統一邏輯。


          否則頁面實現太過復雜也會影響整體體驗和頁面性能。一般通欄、等分結構的布局適合采用彈性布局方式,非等分的多欄結構布局則需要采用混合布局的實現方式。


          選型

          如何考慮實踐過程中的判斷呢。一是看應用場景,二是看如何設計“響應式”方案。簡單、輕量的頁面直接用media query實現響應性就很好。比如blog、小型企業站之類。現在的CSS框架基本都具備響應性。


          但請注意響應式不僅僅是響應式布局。對于大型站簡單用media query是遠遠不夠的。于是在同一個controller層上,識別UA,渲染不同版本的模板,組合相應的靜態資源。這也算是響應式。開發及維護成本明顯提高。

          當各個版本間的差異很大時,維護成本很可能會大到無法接受。即便分開做,架構上也要調整,后端服務化,應用層app化。


          根據不同公司的技術特點,調整的成本也難講是否可行。對于大型站,分開做更清晰,同時用響應式組件解決復用、功能同步的問題??傊鶕鼍绊憫娇梢詮母鞣N層面,各種粒度上做。這是現代web開發的特點。


          建議開發一套響應式電腦網站(過渡到平板端,不過渡到手機端)和開發一套響應式手機端網站(過渡到平板端以下的尺寸,不過渡到平板端)響應式布局有可能造成冗余的代碼較多,對研發的要求也更高,比如如何更好地讓圖片,適配,UI動畫自適應各種布局。


          大站還是要考慮數據計算和承載的問題,會對桌面和移動端輸出不同數據,減輕壓力。



          實踐與技巧

          首先,我們需要了解幾種分辨率的差別。


          ps:原生應用可查詢橫縱兩個方向的像素密度,通常瀏覽器可查詢1個系統像素對應多少物理像素。而設計角度通常需要參考的是所獲取的系統分辨率


          以一個SaaS類后臺產品為例,對于基本流量來自Web端網頁的產品而言,需要了解當下的瀏覽器分辨率現狀 Web端不同屏幕分辨率占比情況,數據來源百度統計,如圖所示:



          如上所述,選擇適配方式時,設計目標為:區分web與pad端可共享的設計布局大于手機端,且產品規劃上web端為主流量來源,pad端屬于短期兼顧??紤]技術維護成本與開發成本的平衡,于是判斷需要選擇A+R模式來完成產品的跨端設計。


          自適應(A)方法能讓我們在不同的設備上有不同的體驗、內容甚至是功能。如將960px作為主要的自適應臨界點,根據全局統計信息定義,我們會得到一些相似處:

          • 左側的可視區代表整個屏幕小于960px時的具體布局和內容

          • 右側的可視區代表整個屏幕大于等于960px時的另一種布局



          在使用響應式(R)技術時,我們可以利用主要臨界點創建兩個互不相同的體驗情景,每種體驗里,我們都可以在可用空間內定義二級臨界點去調整布局。



          通過結合自適應和響應的方法,我們得到A+R模型。利用自適應技術,我們將致力于體驗和功能,作出兩種不同的情景設計。使用響應式組件,我們可以處理上下文內的UI組件和布局。



          這種設計方法要求設計師真正了解他們想要提供的體驗,以便于定義要遵循的模型。此模型非常適合那些在較少功能或結構完全不同的小型移動設備上運行的大型APP。就像你看到的,你的產品將具有很強的靈活性,但同時也很復雜。


          因為你要處理不同的代碼庫和環境(非強制性),Twitter、Facebook和Github將此模式應用在他們的移動網站上。如果你在移動設備上瀏覽這些網站,則可以根據移動用戶的期望來檢驗它們是如何改變的用戶體驗的。


          其他輔助手段


          刪格

          柵格系統可以幫助我們設計,但卻不能保證我們的設計。它有多種可能的用途,并且每個設計師都可以尋找適合其個人風格的解決方案。對于簡化復雜的響應式布局規則而言,這是一項十分有效的輔助手段。


          1. 列和槽(Columns and Gutters)列(Column)用于對齊內容。其中的槽(Gutter)是指相鄰列之間的空間,把控頁面留白,有助于分隔內容。



          2. 頁面邊距(Side Margins)頁邊距是指內容和屏幕邊緣之間的空間。將邊距寬度定義為固定值,這些值決定了每個屏幕尺寸的最小呼吸空間。



          3,用于組成柵格的列數稱為列結構。8、12、16和20是響應式布局中最常見的幾種列結構。而這取決于我們對產品的設計要求。12列結構是相對靈活的。它可以進一步細分,將內容排列在4-4-4或3-3-3-3大小的文本框中,也有部分設計系統采用來24列的形式,如Ant-D

          4,斷點是指屏幕尺寸的特定范圍,列結構、列寬、槽寬和邊距都取決于斷點。在這個范圍內,布局會根據可用的屏幕尺寸重新調整,以獲得最佳的布局視圖。


          如果較小的屏幕有足夠的可用空間容納內容,則列將按比例縮小。如果一列的內容無法在較小屏幕上顯示,該列將垂直放置圖文內容。

          5,網格規則,列跟槽的寬度是以網格作為基本單位來做增減,所以應該先定義好柵格的原子單位,“網紅款”8點網格指的是設計頁面時,也應該遵循8點規律。值得注意的是,列跟槽的值盡量取8的倍數,但不是非得是8的倍數。


          產品中各類元素應該遵循這個倍數原則(圖標、組件大小等),不同的設計系統根據自身需求,設定這個規則。例如在Material Design中使用的是2X網格。

          6.流體柵格與混合刪格

          流體柵格有不同寬度的列,固定的槽和固定的邊距。流體柵格有靈活的內容寬度,根據屏幕大小變化在流體柵格中,列可以增長或收縮以適應可用空間。


          混合柵格既有不同的寬度,也有固定寬度。在現代布局中,一些元素超出了網格邊緣,與屏幕邊緣對齊。頁眉、頁腳、出血都是一些常見的例子。


          如果內容寬度大于可用的屏幕尺寸,那么一個固定柵格就會轉變成一個適應屏幕可用空間的流動柵格,以充分適應內容。

          結語


          設計需在技術方案前介入,根據你的產品特點,進行設計方案評估,可借助的手段有刪格,網格規則等,設計斷點規則時,需關注設備的常見系統分辨率。


          移動和桌面設計的差別遠不止是布局問題。只要有足夠的編程量,這些差別是可以通過響應式設計來解決的。事實上,你可以認為如果一種設計不能兼顧兩種平臺的主要差別,就不能算是合格的響應式設計。


          但是,如果確實想要處理好平臺間的所有差異,我們就回到了原點:進行兩種不同的設計或者使用A+R的模型,在尋求合適的過程中,關注技術的革新。


          A與B不是硬幣的正反面,它們為了解決同一個問題而生,是同一種思想的延伸。

          文章來源:站酷 作者:酷家樂

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務



          超詳細教程教你們如何將node項目部署在云服務器上

          前端達人

          引言

          因為自己學習了前端大部分知識,然后想自己做網站,于是學習了node.js,可不知道如何將項目發布到網上,所以花了很多天的時間,搜集了很多的資料,才將項目部署到服務器上,這里給大家分享一下我的部署過程,以免大家走彎路。

          • 公眾號:前端印象
          • 不定時有送書活動,記得關注~
          • 關注后回復對應文字領取:【面試題】、【前端必看電子書】、【數據結構與算法完整代碼】、【前端技術交流群】

          正文

          一、購買服務器

          這里我們就用騰訊云的服務器吧,因為優惠感覺還是比較大的,性價比也高。

          先進入學生頁面,購買優惠的服務器套餐,每個月才10元,學生服務器優惠套餐鏈接 。也可以參與限時的秒殺活動,一年才99,用來學習再合適不過了,服務器顯示秒殺鏈接。 如果需求大的話,也可以直接買那些高配的服務器其他服務器鏈接
          在這里插入圖片描述
          購買中,所有都默認選項。

          購買完成后, 進入控制臺
          在這里插入圖片描述
          在這里插入圖片描述
          然后重置一下密碼,一定要記住
          在這里插入圖片描述
          我們鼠標移到這看一下服務器的系統是不是CentOS, 因為我們要用到這個版本
          在這里插入圖片描述
          如果不是的話,就可以點擊重裝系統, 自己選擇一下CentOS這個系統即可,并且重裝時設置的密碼也一定要記住哦。
          在這里插入圖片描述

          這樣一臺服務器也就購買成功了。

          二、登錄服務器

          1. 網上下載一個xshell5, 用于我們登錄我們的服務器
            Xshell5下載地址

          2. 下載好以后,打開Xshell5, 點擊新建
            在這里插入圖片描述

          3. 去復制一下我們的公網ip
            在這里插入圖片描述

          4. 然后按以下提示輸入

          在這里插入圖片描述
          以下配置完成后直接點確定
          在這里插入圖片描述
          在這里插入圖片描述
          在這里插入圖片描述

          三、給服務器安裝寶塔面板

          在下圖輸入框中,輸入以下代碼,并按回車

          yum install -y wget && wget -O install.sh http://download.bt.cn/install/install_6.0.sh && sh install.sh 
          
          • 1

          在這里插入圖片描述
          遇到該命令,直接輸入y 然后回車,就他自動安裝吧,時間就點長,耐心等待一下
          在這里插入圖片描述
          安裝好后,會出現這個圖示界面

          • Bt-Panel:是我們即將訪問的網頁地址
          • username: 該網頁的登錄賬號
          • password: 該網頁的登錄密碼

          在這里插入圖片描述
          訪問該頁面, 并輸入相應的賬號密碼進行登錄
          在這里插入圖片描述
          登錄了以后點擊 直接安裝
          在這里插入圖片描述
          這時候別閑著,去軟件商店里,找到這兩個軟件安裝一下
          在這里插入圖片描述

          四、配置服務器、網站

          先回到我們的騰訊云控制臺
          在這里插入圖片描述
          在這里插入圖片描述
          按下圖輸入,并點完成
          在這里插入圖片描述
          接下來就可以將我們的項目放到壓縮文件中,然后上傳到寶塔面板中了
          ,上傳好后直接點解壓就可以了在這里插入圖片描述
          找到我們的pm2, 開始設置我們的項目
          在這里插入圖片描述
          在這里插入圖片描述
          然后點擊映射,將我們的公網ip 映射一下
          在這里插入圖片描述
          如果這里的端口是3000,我們需要將入口文件中的端口號改一下,我這里是改為5000了
          在這里插入圖片描述
          入口文件的端口號修改好后,我們需要放行一下我們項目網站的端口號,即做以下兩個步驟
          在這里插入圖片描述
          在這里插入圖片描述
          然后重啟一下項目
          在這里插入圖片描述
          這樣一個node.js項目就部署完成啦,接下來就通過公網ip + 端口號的方式進行訪問
          在這里插入圖片描述
          可以看到訪問成功了。

          結束語

          這是我查閱了大量資料,才部署上去的node.js 項目,因為我是做前端的,所以不太懂運維這些的,只能做這樣一個簡單的部署, 不過對于新手學習已經完全足夠了,希望這篇文章能幫助到你們。


          轉自:csdn 作者:「零一」

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          接口測試之(在Linux上搭建Tomcat環境)

          前端達人

          接口測試:

             接口:是傳遞數據的通道。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。

             測試的重點是要檢測數據的交換,傳遞和控制管理過程,以及系統間的相互邏輯依賴關系等。

          接口的分類:

            外部接口:調用第三方平臺的接口

            內部接口:登陸和注冊這種單獨的內部接口


          1、首先下載好tomcat軟件包

          2、通過Xftp軟件傳輸到我們Linux虛擬機的  /opt目錄下

          3、通過Xshell我們可以在/opt目錄下看到tomcat軟件包(如下圖紅色框內)

          4、我們解壓tomcat是用:tar -xzvf apache-tomcat-8.0.30.tar.gz    命令進行解壓,可以看到解壓后的文件(如下圖綠色框內)因為我已經解壓過了,就不給大家示范了(這里要注意的是因為我在opt目錄下的,所以用這個解壓命令,如果你沒在你要解壓的目錄下就要在后面加 -c 這個參數)


          5、接下來我們下載JDK(注意JDK的位數和系統區別):我是在64位Linux系統部署的

          6、上傳和解壓和tomact一樣都是tar.gz格式的,解壓命令都一樣,也是放在opt目錄下

          7、驗證JDK是否安裝好(java -version)


          8、在其他目錄下執行(java -version)是不成功的,所以要配置JDK環境變量,通過編輯 vi etc/profile  在最后段加上

          JAVA_HOME=/opt/jdk1.8.0_141     -----》改成自己的jdk路徑

          JAVA_BIN=$JAVA_HOME/bin

          JRE_HOME=$JAVA_HOME/jre

          JRE_BIN=$JRE_HOME/bin

          PATH=$JAVA_BIN:$JRE_BIN:$PATH

          CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib

          export JAVA_HOME JRE_HOME PATH CLASSPATH


          9、然后輸入  source /etc/profile命令,使環境變量生效,現在使用Java -version目錄下驗證JDK是否已經全局生效  

          10、在bin目錄啟動tomcat,查看tomcat環境是否能可以啟動(  ./startup.sh  啟動       ./startup.sh 關閉 )


          11、訪問地址出現如下圖證明tomcat環境搭建好了(你自己虛擬機的IP+tomcat的端口號)

          12、修改tomcat的端口號,目錄:在/opt/apache-tomcat-8.0.30/conf,用vi server.xml 修改端口號

          13、注意:啟動tomcat要關閉防火墻,最后養成打開日志文件習慣

          轉自:csdn 作者:寒門子弟


          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          如何將訪客轉化為潛在客戶?這個8個網站優化策略了解下

          seo達人

           

          文章目錄

          你是否已經將自己的網站優化到最佳狀態了呢?通過優化來產生潛在客戶是轉化網站已經獲得的流量的最好方法之一。

          然而,如果你認為在網站的主頁上添加幾個“點擊這里”的CTA策略(站長之家注:CTA即Call-to-Action,行為召喚,指在網站、App中用于引導用戶自發完成某種特定行動。)就能獲取更多的潛在客戶,很遺憾的說,這個想法大錯特錯。

          在這篇文章中,將為大家介紹通過網站優化將訪客轉化為潛在客戶的 8 關鍵策略。

          202005221429282567_3.jpg

          實時聊天和聊天機器人

          這是對任何網站的一個重要的補充。你可以與網站訪客的人進行對話,以獲得建議、指導、幫助,有時甚至是銷售。實時聊天通常會出現在網頁的底部,會出現一條自動消息,比如“我今天能幫你嗎”,然后你就可以開始對話了。

          你扮演數字客服的角色。重要的是,實時聊天不要出現在網站的每個頁面,因為用戶可能會覺得這樣做相當煩人。

          因此,建議在網站的主頁和服務頁面上開啟在線聊天功能。因為主頁是用戶在點擊網站時通常會看到的第一個頁面,因此實時聊天彈出窗口應該充當問候消息。從服務層面來看,它可以為用戶提供關于產品的建議或幫助。以京東首頁為例,右側就提供了“客服”服務,實時為客戶答疑解惑。

          6372679711486955265571061.png

          聊天機器人是進一步開發實時聊天功能的工具。聊天機器人是一種軟件,它提供自動的、預先確定的響應,這些響應被編程為像人類一樣的行為。

          聊天機器人可以提升網站體驗,因為它們可以幫助你自動識別潛在客戶和查詢,從長遠來看可以節省你的時間。一旦設置完成,你需要做的就是偶爾檢查一下信息,以確保信息仍然適合你的目的,然后你就可以離開了!

          提供可下載的內容

          提供可下載的指南、博客和見解對于數據獲取以及允許訪問者直接與網站產生互動都非常有用。

          3.jpg

          可下載內容要從銷售流程開始,如果內容已經被下載,這意味著潛在客戶已經對你的產品或服務產生了興趣。這樣就避免了尷尬的對話,而銷售人員就可以開始向潛在客戶推送更進一步有用的內容。

          通過簡單地添加一個CTA,就可為自己節省了許多陌生對話。

          可下載的內容也使網站更具互動性。您可以通過在用戶下載內容之前添加要填寫的表單來捕獲關于用戶的數據。然后將數據保存并放入CRM中。接著,您就可以創建工作流,用戶將在其中接收其他內容塊。

          請記住,為了讓人們下載網站的內容,提供的內容必須對他們有價值。否則,雖然網站登錄頁面點擊量很高,但下載量卻少得可憐。因為如果用戶沒有給出他們的聯系方式,也意味著提供的內容沒有價值。

          所以,如果你花時間和資源去制作一份有真正價值的高質量內容,那么就會獲得不錯的投資回報率(ROI)。

          提供動態、智能的CTA

          僅僅增加一個“點擊這里”或“了解更多”是不夠的,CTA在最近幾年變得流行起來,所以你網站的CTA一定要大膽、獨特,并與網站、博客、指南等相關。

          4.jpg

          行動呼吁的作用不僅僅是一個帶有命令的彩色按鈕,在某些情況下,它們是一些細微的差別,可以產生巨大的影響。

          有兩種類型的CTA,主要的和次要的。

          主要的CTA是你希望客戶采取行動的地方,例如“立即購買”、“立即申請”。

          次要的CTA的目的讓用戶了解某些主題或服務。例如,“了解更多”、“繼續閱讀”,目的是為客戶提供進一步的信息和細節。

          現在很多營銷平臺已經有直觀的系統來幫助創建CTA。例如,HubSpot就建立“智能CTA”,這有助于優化訪客的網站體驗。

          本質上,智能CTA使用動態內容在合適的時間向聯系人顯示合適的內容。CTA會根據訪問它的用戶而改變,你可以根據選擇的標準為不同的用戶提供不同的CTA,而不是死板的同一內容。

          這有助于根據訪問者不同的訪問階段,為他們提供個性化的品牌體驗。

          通過工作流程培養潛在客戶

          沒有一個潛在客戶就能保證成功銷售,所以需要確保引導他們的方式是正確的,讓他們通過你的銷售渠道進入你銷售周期的決策階段。

          一旦潛在客戶下載了您的一部分內容,就可以將他們放入工作流程中。然后發送讓他們感興趣并且有價值的內容。

          例如,如果潛在客戶下載了“成功重新設計網站的 7 個步驟”資料,我們不會向他們發送關于SEO或潛在客戶生成等主題的內容,而是繼續圍繞他們最初表示感興趣的主題提供相關內容,并繼續讓他們參與我們的服務。

          你的目標應該是通過銷售漏斗推動銷售,直到他們能夠購買為止。熱情、自動化(但仍然是個人)的電子郵件有助于加快銷售進程。

          根據國外數據報告顯示,培養潛在客戶的公司比不培育潛在客戶的公司“潛在銷售客戶”多50%,而成本則低33%。

          提供表格提交選項

          提供可下載內容的表單是為企業獲取數據的另一種方法。表單通常存儲用戶必要細節和信息,包括姓名、性別、業務、電子郵件和電話號碼。

          5.jpg

          表格應該添加到的網站上吸引最多流量的頁面。通過設置百度分析之類的統計工具,就可以看到有多少人在訪問你的網站,有多少人實際上點擊了表單。

          表格也有助于建立電子郵件列表。如果你的標準包括在網站上填寫表格時的電子郵件,就可以將它添加到你的郵件列表中。郵件列表中的潛在客戶越多,就越有可能通過你的內容收到下載、咨詢或回電。

          展示正面評價案例

          當你購買一個新產品的時候,是否會去看看別人的評論和建議呢?

          可能90%的人都會。因此提供評論和證明,可以幫助用戶作出最終的購買決定。

          那么,為什么不利用那些顧客的積極的評價來幫助推銷你的產品呢?

          6.png

          《心理科學》雜志發表的一項研究強調,當讓人們在兩種相似的產品中進行選擇時,大多數人會選擇評論最多的產品。

          最近,TrustPilot(全球最大的在線評論社區)發現92%的消費者表示購買決定受到在線評論的影響。他們還發現:

          • 72%的消費者會在閱讀正面評論后采取行動

          • 88%的消費者相信評論和個人推薦

          雖然這些發現主要集中在B2C,但也有證據表明,評論和評價在B2B決策過程中變得越來越重要。

          根據 2018 年一份關于評論對B2B買家和賣家的影響的報告顯示,92%的買家更有可能在閱讀了可信的評論后購買產品或服務。然而,目前只有43%的B2B企業將評論作為其營銷策略的一部分。

          這顯示了B2C和B2B企業的巨大潛力,它們不僅可以為網站添加推薦信,還可以滿足TrustPilot等平臺的需求。

          適當的彈窗設計

          如果使用不當,彈窗可能讓用戶感到相當的惱怒。相反的,如果合適應用的話,則能起到非常有用的效果。關鍵是不要過早地在每一頁上都應用到彈窗。任何人都不想要在剛登錄一個網站頁面就巨大的彈出廣告。

          您應該為彈窗設置一個觸發器,例如,如果它們滾動到站點上的某個特定部分或某個特定頁面上。一些彈出窗口非常有用,因為它們可以觸發對話并立即吸引用戶的注意力。

          亞馬遜有一個非常好的彈窗設置,它不是太大,并促進一個非常明確的信息。在“你的賬戶”旁邊有一個彈出框,上面寫著“新客戶,登錄嗎?從這里開始”。

          你可能沒有捕捉到潛在客戶的所有的細節,但比以前更接近目標了。

          測試,測試,再測試

          最重要的一項工作,它它并不是一個真正的功能,但它對任何網站來說都是至關重要的一步,也是大多數企業主不夠重視的地方,那就是測試。

          像A/B測試這樣的方法是非常有效的,并且可以提高網站的點擊率(CTR)。

          A/B測試是使用一個變化元素來比較網頁、電子郵件或其他營銷資產的兩個版本的過程。

          在網站上測試一些簡單的功能,比如CTA,登陸頁面的布局,圖片和不同類型的內容,都會對網站的成功產生巨大的影響。

          反復測試,直到找到最有效的部分。

          結論

          越來越多網站不斷的更新優化,作為企業主關鍵就是要積極主動擁抱變化。你需要依靠潛在客戶發展自己的業務,那么使用上面的技巧,把你的網站訪問者轉化為潛在客戶的挑戰變得簡單了一點。

          注:文章編譯自medium

          文章來源:站長之家

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

           

          體驗好的電商APP長啥樣?這里總結了7種絕佳的UI設計原則

          seo達人

           

          最近,國外設計師Jennifer Jhang對一些頂級的電子商務APP如耐克、蘋果、三星、Ebay、Banggood以及Best Buy等產品進行了研究,并總結了 7 種主要的用戶界面模式。

          1. 登錄:多個選項

          登錄通常是第一個障礙,設置不當會導致用戶花費很多精力在上面。為了減少用戶登錄的難度,可以增加登錄的靈活性。

          嘗試“懶人”登錄模式。這種情況下,應該設計可選擇的登錄選項,比如可以讓用戶直達購物車或者其他功能。比如允許用戶在創建賬戶之前,可以用游客的身份試用APP并體驗其價值。

          另外,考慮通過將登錄選項直接關聯外部賬戶如Facebook、谷歌(國內的比如微博、微信等)就能注冊新的賬戶登錄。這讓用戶可以跳過填寫注冊表單,而只需單擊 2 次即可登錄。

          111111.jpg

          在Banggood的賬戶界面,你可以清楚的看到,想要訪問“已查看”、“優惠券”內容就需要登錄,Banggood還在登錄時提供關聯外部賬戶選項。

          2. 搜索:支持文本、圖像、聲音、條形碼

          Pinterest CEO說過:“我真的相信相機將成為下一個鍵盤。”

          互聯網開始于一個基于文本的搜索欄,但正在演變為可以采取其他多種方式進行搜索。比如采用一個文本和圖片方式的組合,無疑可以增強搜索交互。

          222222.jpg

          通過視覺人工智能,圖像搜索開辟了一個新的搜索方式。你不僅可以通過視覺線索識別產品,圖像搜索還可以讓你基于圖像上下文發現新想法。例如,如果你拍了一張西紅柿的照片,搜索結果可能會提供西紅柿炒蛋的食譜。

          另外掃描條形碼可以減少出錯的可能性,并能讓你直接找到產品。語音搜索增加了可訪問性,并為忙于其它事務的用戶提供了便利。

          3. 瀏覽:產品類別

          除了直接搜索,用戶還參與瀏覽來查找商品。產品類別可以讓用戶更清晰有序的的方式瀏覽和發現產品。

          產品類別通過以一種直觀的方式將產品進行分組,從改善用戶搜索查找產品的能力。這就像走進一家雜貨店,一眼望過去就是的我們想找的商品商品擺放的大概位置。

          很多應用程序有一個單獨的產品分類屏幕。其他的包括在“主頁”頁面上的產品類別部分。為了能向用戶提供更愉快的瀏覽體驗,可以考慮將圖像或圖標與類別標簽結合起來。

          下面,你將看到每個應用程序處理產品類別顯示的不同方式。

          3333333.jpg

          4. 卡片的多樣性和一致性

          卡片是用戶首先與APP交互的UI元素??ㄆ亩鄻有院鸵恢滦杂兄跒閼脛撛煲粋€讓人深刻的第一印象。

          嘗試為不同類型的信息創建不同類型的卡片。這在視覺上區分了信息,并幫助用戶學習視覺語言。沒有多樣性,很難一眼就看出一張卡片代表了什么,因為它們看起來都一樣。

          另外,也要努力使卡片在每個屏幕上保持一致。如果你有一個特定信息的卡片類型,試著讓它始終保持相同的設計風格和尺寸大小等等,這樣它才容易識別。

          蘋果商店使用了多樣性和一致性,創造了一個清晰的視覺詞匯。

          44444.jpg

          5. 不同用戶階段采用不同的CTA(行動呼吁)

          本文開頭提到的幾個APP中采用的CTA按鈕有幾種常見模式。通常在用戶不同瀏覽階段會有不同的CTA按鈕。

          55555.jpg

          例如,Ebay有連續的“保存”、“添加到購物車”和“現在購買”按鈕。當你想立即購買某一特定物品時,“立即購買”是很好的選擇。然而,當用戶等待打折或比較商品時,“省錢”按鈕則是更好的選擇。“添加到購物車”在用戶一次購買少量物品時很有意義的。

          而當用戶還沒有完全準備好購買時,頁面只有一個“現在購買”按鈕,那么無法解決他們的加購需求。這可能會阻礙用戶的購物體驗。

          6. 特定產品頁面的頂部標簽

          為了試圖包含購買決策所需的所有細節,特定產品的詳情頁可能很長。

          根據尼爾森的一項研究,以下是一個產品頁面最受歡迎的功能列表:

          必須擁有:產品名稱,圖像,價格,選項,可用性,添加到購物車,描述

          值得擁有的:評級或評論,附加圖片,視頻,縮放/平移,相關推薦,愿望列表

          在頁面頂部放置標簽是幫助用戶快速找到感興趣話題的一種方法。它們甚至在用戶開始向下滾動之前就顯示屏幕內容。

          標簽應該包含相同層級的相關內容,同時應該要可展開更多詳情。在添加主題時,可以使用可滾動的固定標簽。

          在這里,Samsung Shop和Chewy使用固定標簽,而Drop使用可滾動標簽。

          66666.jpg

          7.付款:漸進式展示

          漸進式展示信息是指顯示適量的信息。它通過多屏展示分解信息,同時仍然揭示主要主題,從而降低了復雜性。

          如果沒有做到這點,用戶可能會覺得結賬很乏味,甚至會放棄購物。面對一張填滿信息的表格會讓人看著難受,看到同樣的表格被分成幾個部分,感覺上就更容易處理。還要記住,你需要在頁面的下半部分留出放置鍵盤的空間。

          組織這種復雜性的一些方法是使用手風琴效果、列表或進度指示器。手風琴垂直展開,展開列表就會展示一個屏幕頁面,顯示更多信息。進度指示器顯示用戶在結賬步驟中的的進程。

          耐克似乎使用了手風琴效果、chewy和使用列表模式,而Drop在結帳時使用了進度指示器。

          777777.jpg

          結論

          通過研究當前的APP,你可以學到很多東西。觀察產品設計決策背后的原因,我們可以找到新的見解。使用合適的UI模式創建一個從下載到結賬的無縫體驗的APP。

          注:文章由站長之家編譯自uxdesign

          文章來源:站長之家

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

           

          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合