本文由数据可视化协会 (DVS) 推荐。你可以去这里到在 Nightingale 上阅读。

每个客户都会问:“您认为这需要多长时间?”我已经构建软件很长时间了。我曾经拒绝回答这个问题。我是Fred Brooks的追随者,我很欣赏一个复杂项目可能会横冲直撞的所有不可预见的方式。

不过我不介意了。这是设定期望的重要组成部分(这会带来快乐的项目和快乐的客户)。而且,对于任何以固定费用工作的人来说,了解给定项目是否会盈利很重要。因此,我不仅尝试估算每个项目的时间安排,还跟踪实际时间以查看我是否正确。

估计和期望设定的挑战之一是拥有类似项目的跟踪记录以供参考。如果您是一家较大的商店,历史悠久且产品组合齐全,那么您就拥有信息优势。

较小的独立商店或自由职业者在其职业生涯的早期没有这种优势,因此可能难以估计。

或者,更糟糕的是,很容易屈服于偶尔过分热心的客户的压力,他们专注于预算项目(“你会花多长时间在研究上?!”)。

共享这些数据的目的是消除信息不对称,并详细说明制作(相当复杂的)数据可视化所涉及的时间和精力。

3iap的时间跟踪数据集

从 2020 年 3iap 开始,重点是为客户提供数据可视化服务。从那时起,3iap 完成了各种项目,涵盖了您作为 dataviz 顾问可能遇到的所有工作(例如,研究、分析、数据整理、度量、设计和各种类型的工程)。我详细记录了每个项目所花费的时间。

截至 2022 年初,3iap 已经记录了约 1,550 小时的客户数据可视化工作(除了销售/营销/文书工作等,+300 小时的一般产品咨询以支付账单,以及愚蠢的未跟踪小时数侧项目)。

除了重点介绍代表一系列不同 dataviz 工作的 10 个具体项目外,以下是关于如何花费时间的调查结果。

有多少“dataviz”工作进入 dataviz?

[](https://res.cloudinary.com/practicaldev/image/fetch/s--g0h_offw--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to -uploads.s3.amazonaws.com/uploads/articles/in4n4jogn5831171k85s.png)

在 3iap 客户项目上花费的 1,550 小时分布,按活动类型划分。

大约 60% 的总时间用于直接设计或工程可视化。

设计+工程

[](https://res.cloudinary.com/practicaldev/image/fetch/s--W2tBSqB0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/uploads/articles/bicm35yfr4tmx5ifyfeq.png)

在 3iap 客户项目上花费的 dataviz 设计和工程时间分布,按活动子类型划分。设计和工程活动合计占总工时的 60%。

31% 的时间花在design上,其中可以包括从story discovery开始的所有内容,通常在探索性分析和用钢笔和记号笔勾勒故事概念之间跳跃(4%),在 Figma 或 Google Sheets 中模拟特定的charts(6%), Observable 中有prototyping种不同的设计方法(3% 设计,3% 工程),甚至偶尔有copywriting种(2%)。

看到这个,我很惊讶slides是第二高的design活动(6%)——我怀疑这是由于工具本身效率低下,而 Figma 可以组件化并且编码数据可视化可以自动化,Keynote 涉及很多手动像素推送。

29% 的时间用于开发可视化,通常使用 javascript(13%React,6%Angular),但偶尔也会使用Data Studio(4%)。这一次也恰逢data-wrangling活动,构建管道以准备数据集以进行可视化。

请注意,设计与工程的比率可能不代表该领域的其他人或特定项目。我的背景是计算机科学,因此对更多技术性工作存在选择偏见。在代码中进行原型设计也是我设计过程的一部分,这进一步模糊了界限。此外,大多数 3iap 项目要么是工程要么设计,而不是两者兼而有之。对于更具代表性的比例,Interactive Scientific Storytelling 和 Complex Report: Analysis & Presentation Design 是涉及设计和开发的项目。

有多少“非dataviz”工作进入dataviz?

[](https://res.cloudinary.com/practicaldev/image/fetch/s--yXtEHerx--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /dev-to-uploads.s3.amazonaws.com/uploads/articles/zglznfj1ahxmo7rp92jq.png)

3iap 客户项目上花费的数据、沟通和研究时间分布,按活动子类型划分。这些活动加起来占总时间的 39%。”

剩下 40% 的总时间用于其他活动。剩余时间分为research、客户端communication和data wrangling。(所有这些都非常重要,但从客户端的角度来看,这可能是不直观的。)

18% 的总时间花在了communicating与客户、用户和利益相关者身上,挖掘故事并试图确保每个人都在同一个页面上。这包括meetings(8%) 和documenting设计、计划和代码 (3%),其余的是电子邮件和 Slack。虽然这看起来有些过分,但沟通是这个过程的关键部分;几个小时的前期会议、读心术和文档可以节省几天的返工。因此,communication的很大一部分时间与其他活动同时发生。例如:总小时数的 7% 被标记为communication和design,这可能包括与客户的共同设计练习或设计审查。

正如预期的那样,在 16% 时,data wrangling和分析占用了总时间的很大一部分。这包括data prep,我将其归类为相当愚蠢的数据工程或电子表格操作 (9%) 或data pulls(3%)。更有趣的数据工作更加分散:约 2% 的时间是exploratory analysis(例如,用于讲故事),约 1% 的时间用于designing metrics(例如,探索可能最能讲述给定故事的不同计算)和另外 1%正在创建mock datasets(例如,为了补偿数据安全限制或提供真实数据缓慢的客户端)。

Research/ 发现占总时间的 6%。大部分时间都花在与客户交谈上,同时与会议、电子邮件和 Slack 相吻合。它还包括行业研究、审查相关学术文献以及客户可用的任何材料。

• 总小时数的 4% 被标记为communication和research,这可能包括客户读心练习、用户访谈或其他类型的定性用户研究。这可能是所有项目中影响最大的时间:这可能看起来不直观,但至少根据我的经验,获得引人入胜的数据故事的最快途径不一定是数据本身,而是与数据背后的人交谈。

混沌/矫枉过正

[](https://res.cloudinary.com/practicaldev/image/fetch/s--Pb-1FGsp--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/uploads/articles/fpuuhwhciicumb8xmh9y.png)

在 3iap 客户项目上花费的总时间分布,按效率低下的原因划分。客户造成“混乱”,而“过度杀伤”时间是自己造成的。

对于某些项目,我还跟踪一个我称之为chaos的类别,由于客户的恶作剧而浪费了时间。这包括在固定费用项目上增加新范围或重新审视导致返工的早期决策。这是总小时数的 8%。

这个类别的倒数是overkill,我对一个想法变得过度兴奋,掉进兔子洞,投入比合理或理智更多的时间。这是总小时数的 4%。

10x 3iap dataviz 项目 - 时间和细节

之前的调查结果涵盖了所有 3iap 项目的总体统计数据。但是,了解单个项目如何使用时间可能会有所帮助。对于下面的每个项目,我都尝试分享足够多的项目范围以了解需求,以及时间花费的总体统计数据。还有一个时间表显示工作类型在整个项目过程中如何演变。

1\。分析产品设计系统(14 天)

一位长期客户要求 3iap 重新设计他们的 SaaS 分析应用程序。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--CJHX53OC--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/zexfns3gsnj19r8ycf13.png)

左:在单个项目上花费的时间分布,按活动类型划分。右图:整个项目过程中的活动时间表。每个“行”对应于八小时(“工作日”)。每个段代表一个活动。磁贴颜色对应于活动类型。具有多种颜色的片段具有重叠的颜色(例如,用户访谈既是“研究”又是“会议”)。线段之间的黑线代表日历日的边界。

一位长期客户要求 3iap 重新设计其大型、复杂的 SaaS 分析产品(涵盖 200 多个不同的指标)。该项目分为三个部分:1)图表组件和支持元素的设计系统可以混合和匹配以回答广泛的分析问题,2)四种不同叙述报告的详细设计,展示设计系统如何能够深入探讨各种分析主题,以及 3) API 设计和技术规范,以在从后端访问数据时实现类似的灵活性/可组合性。因为这是一个熟悉的客户和主题,所以几乎不需要研究或数据争论。

2\。产品内图表组件(11 天)

3iap 在客户现有的代码库中开发了一个交互式图表组件和自动化测试框架。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--hk5yIEZi--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/sifc1097qqcyepjfnavj.png)

左:在单个项目上花费的时间分布,按活动类型划分。右图:整个项目过程中的活动时间表。每个“行”对应于八小时(“工作日”)。每个段代表一个活动。磁贴颜色对应于活动类型。具有多种颜色的片段具有重叠的颜色(例如,用户访谈既是“研究”又是“会议”)。线段之间的黑线代表日历日的边界。

目标不仅是交付组件,而且还开发一个模板,用于在其环境中如何可靠地开发和测试其他图表。组件本身相当简单,挑战在于让它在他们的系统中(可靠地)工作。这个项目相当混乱。除了最后一分钟的范围蔓延之外,启动代码库也不以其质量或工程实践而闻名。这里没有判断,但这增加了很大的阻力!

3\。复杂报告:分析和演示设计(24 天)

分析一个复杂而新颖的主题,对 3iap 和客户来说都是新的,设计适当的可视化,然后在 51 张幻灯片中讲述一个有凝聚力的故事。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--ispqY05U--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/inod2sq98afgeffxny81.png)

左:在单个项目上花费的时间分布,按活动类型划分。右图:整个项目过程中的活动时间表。每个“行”对应于八小时(“工作日”)。每个段代表一个活动。磁贴颜色对应于活动类型。具有多种颜色的片段具有重叠的颜色(例如,用户访谈既是“研究”又是“会议”)。线段之间的黑线代表日历日的边界。

这涉及为客户研究一个新主题,设计和开发新颖的可视化,与他们的数据工程师密切合作开发一组新颖的指标,多次分析迭代,开发一个框架来生成展示分析的图表,然后设计一个平台讲述整个故事。虽然这是该批次中研究/分析最繁重的项目,但这些活动仍然只占总时间的 38%(26% 数据 + 12% 研究)。

4\。嵌入式报告工具设计(12 天)

具有独特数据集的 SaaS 初创客户要求 3iap 设计、原型和用户测试他们的产品内分析 UX。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--yTaLk3u2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/54ee1s14mslq4xu5wr44.png)

左:在单个项目上花费的时间分布,按活动类型划分。右图:整个项目过程中的活动时间表。每个“行”对应于八小时(“工作日”)。每个段代表一个活动。磁贴颜色对应于活动类型。具有多种颜色的片段具有重叠的颜色(例如,用户访谈既是“研究”又是“会议”)。线段之间的黑线代表日历日的边界。下面的行显示了项目的实际工作天数,相对于原始估计。

该项目涉及研究他们的行业、产品和数据集、设计指标以反映他们想要跟踪的活动、在 Figma 和 Data Studio 中设计和原型化 4 个“实时报告”、促进用户测试并相应地进行调整。客户是敬业度、思想开放和精通数据的理想平衡点。他们在第一天也有可用的数据。项目进展顺利,提前完成。

---

请在3iap或数据可视化协会的Nightingale上查看文章的其余部分。