What is the impediment to a data-driven design process?

Question

Many government organisations and agencies are adopting the GOV.UK - GDS design principles, and it has certainly resulted in the trend of government websites becoming less cluttered and content-focused. However, I think this really only goes as far as the visual aesthetics and basic interactions of the website, and when it comes to the user transactions and processes, the guidelines are much more difficult to implement.

The most significant illustration of this I believe is principle number 3: Design with Data.

In fact, I would argue that this design principle doesn't go far enough and should be Design using Data because it then opens up the discussion of better standards in the implementation of infographics and data visualization in government websites that also help users to make decisions (not just the website administrators and government managers/executives), and it also links to the open data initiative.

I am interested to find out what the impediments to data-driven design processes are in various companies and organisations. I believe the key obstacles are:

• Uniform/unified standards for data collection and management
• Lack of understanding about information/data design best practices
• Lack of data transparency within the organisation
• Lack of understanding about research/testing best practices

Are there others that I am not aware of that might also contribute to this?

Answer 1

Designing data visualisations is a different topic to designing with data. Just because they share the word data doesn't mean they have significant overlap or synergy otherwise we could lump databases in as well. The latter is about using statistics on behaviours, use and users (real and potential) to guide and improve a product - digital market research. The former is about designing a visually oriented interface that reveals meaning/patterns/outliers in specific combinations of data types, tasks and users. Models and processes for that are different with marked nuances, e.g. see:

https://www.cs.ubc.ca/labs/imager/tr/2009/NestedModel/NestedModel.pdf doi: 10.1109/TVCG.2009.111

http://publik.tuwien.ac.at/files/PubDat_223990.pdf doi:10.1016/j.cag.2013.11.002

Answer 2

I think your list is a good start! Those four are tough, and together they point to an even larger problem: Lack of resources to implement and maintain a usage metrics regime.

The phases and components of web-based software projects form a sort of Maslow's Hierarchy of Needs, where project stakeholders view some components as critical and others as "nice to have". When resources for carrying out a project are limited, as they almost always are, the things at the bottom of the list get cut.

Here's what I see the typical priorities to be, from most essential to least essential:

1. Build (that is, actually coding it and deploying it)
2. Content Development
3. Graphic Design
4. Ability for not technical stakeholders to update the content (aka CMS)
5. Progressive iteration (i.e. making it better over time)
6. Information Architecture
7. UX Design
8. QA
9. Acessibility
10. Implementing and maintaining a usage metrics regime

Again, this is not my priority list, but what I've seen over my 18 years of building websites and web applications.

The core of the issue you point to, I think, is that people tend to prize progressive iteration OVER implementing a usage metrics regime – when you and I know that you can't effectively do the former without the latter.

Answer 3

I think what you should also consider is that companies that or focusing on creating new applications/web/software, whatever project will likely not have data to make such decisions. Of course there is research but nothing can replace real analytics.

Answer 4

I dont think Design (only) using Data is the right way. Design will always be qualitative, subjective and driven by expertism.

You never will get good design purely based on numbers. May be you get medium, pleasing design as it will be attractive by the majority 50%. Designers usually learn at University why and how they decide/ choose for the creation, this is led by objective, established design rules as well.

Data can support design but never lead. Data can tell you the "How" and "How many", but never the "Why". And even data has to be interpreted in order be informative. And these are the impediments - it doesnt make sense to only use data or data as the leading force for design.

No business (despite Facebook et al) will gather data without any usage scenario. It costs money to set up the infrastructure and feed the servers. Give them a decent business case for data collection and executives will collect it. Just telling them "Hey data is the new stuff" wont convince anyone. Because there are others crying "Devops", "Internet of Things", "Mobile Payment" and and and.