The UX Design Strategist
Shares

Taxonomy – A UX Secret Weapon

Shares

Why Knowing Your Data is Critical

Taxonomy is the science of classification and hierarchy that began in the worlds of science and biology and can be quite useful in the tech world of data and content (which I’m going to classify here as data for simplicity) in ways that might surprise you. And the UX I’m referring to isn’t the “make it pretty” UX, which is really UI – User Interface. The UX I’m supporting here is the ground level UX that unfortunately a lot of companies say they don’t have time for: RESEARCH UX. And what we need to research is data.

The key is Simplification 

In older companies, those that have been through many eras of technology, legacy data may still be crucial to their survival, and it can’t be dumped overnight. Create a thorough taxonomy in this situation and you’ll understand my point. “Wow! That’s still in there?!” has been uttered by many a CEO when shown 20-year-old metrics.

Careful sifting and data sciencing must be completed to match up newer terms with old in order to make a shift and simplify procedures, workflows, algorithms, and day to day business in general. 

Every company wants to stay in business. Most companies want to grow and increase market share. Data ambiguities and terminology overlaps can slow and even halt that progress. Taxonomy to the rescue!

You can agree or disagree with me and either way is fine but please understand my point: taxonomies can be very powerful tools in getting the varied constituents in a business aligned and working more efficiently. And dare I say – “unsiloed”?

Terminology Ambiguities

In project after project that I’ve worked as a UX researcher and strategist I’ve encountered this more times than I can count. I’ll get a spreadsheet from one department with 25 columns covering the data that is most important to them, and I’ll get the same spreadsheet from a department that supports the other, this one with 30 columns. Or I’ll have two departments at the table talking and neither understands the other when we start flinging terminology around the table.

Scenario 1

UX Researcher: So, Richard, help me understand these 5 extra columns. When I got the spreadsheet from Clare in accounting those were missing.

Data Steward: Yep. Those are calculated fields in the database and her department takes them out when they get the files from us.

UX Researcher: Okay, I’ll talk to her about that one then. I also found these 6 columns that have differing names. Her department calls them one thing and you call them another. I’m trying to reconcile the differences and see if we can all agree on one name, so that everyone is on the same page. Can you walk me through that please? 

Scenario 2

Designer: We’re going to need to redesign the deacceleratorizer.

Engineer: What’s that?

Designer: You know – the thing the person pushes with their foot to make the motorized contraption slow down.

Engineer: Oh! You mean the haltificator!

Designer: No. I really mean the deacceleratorizer. I have no idea what you’re talking about. *** And of course the designer goes back to Design Central later and tells the team what the engineers think the thing is called and they all have a good laugh while the engineering team is shaking their heads and doing the same with the other term.

These conversations can go in a few different directions from here, from quick agreement in most smaller companies with a narrower field of terms, to days of work with our cross-functional teams to gain alignment between the stakeholders, data stewards, and upper management. And while on the surface some of the arguments for why this data, term, name… can seem trivial, remember that your couch is someone else’s sofa and someone else’s davenport, and you have no idea why they would call it anything else. 

Application Design

We go through the data discovery exercises as quickly explained above because we have to design and build something. Whether that’s a website or an application doesn’t matter. My experience is with both, with the concentration in application design so let’s stay there.

Every application is supported by data, which means that every company is supported by data. Hospitals, banks, manufacturers, service companies, stores, builders, and on and on, all rely on data to survive. 

Is the data accurate? If not, bad decisions will be made, and the application will be to blame. Been there done that, have the tshirt.

And if we agree that the data is accurate, but we use it in ways that don’t support lines of business and the needs of the data workers who pump out analysis and reports that are meant to drive business, then we’re burning $$$$ heading in the wrong direction.

Hmmmm… I wonder if a taxonomy can help with this challenge. Why yes! Yes it can!

UX = User Experience. No arguments there. I hope.

The greatest service that you as a practitioner of the UX alchemical practices can provide to a project is to get a firm grasp on the data. I don’t make a move until I’ve studied spreadsheets, fed the data into taxonomy or ontology tools like Protégé or Hozo, built charts with data viz tools like Tableau, High Charts, or Gephi, and then interviewed as many of the creators and users of the data that I can get into a room for 25 minutes.

Case in point. (Summarized for anonymity.)

A company in the south west, responsible for servicing certain types of financial transactions between individuals and corporations. Dev team gets ahold of BI software and makes an application to be used by service reps. Dev team thinks they’ve hit a home run and when interviewed give their application 10 stars. Service reps wonder how and why the devs would give them such an unusable collection of nonsense and rate the application an average of 3.5 stars. Major fail.

While the devs understood the data, they didn’t understand what parts of the data mattered to the service reps or how the data was/were used. This is absolutely critical information to have. 

What was discovered through both data and user needs research was that terms were jumbled as well. Before the BI tool came along, the business got the spreadsheet from tech, took out columns they thought didn’t matter to them, renamed half of the columns to fit their world, and then tried to do their work.

Along comes this fancy BI tool, which “looks okay I guess” but isn’t usable, isn’t relevant, and “actually makes my life more difficult”. Susan never looks at these three columns, and Pete is wondering why his specific data on quality assurance measures isn’t in the tool.

The dev team needed a taxonomy of the fields needed by the users, what the users called them, and how they might be using these to do calculations that would allow them to make the business run smoother so that customers stayed happy, engaged, and returning for more. They needed to understand the data domains that were important to the users.

When you or I get into the groove of a job, we learn to weigh certain factors together or differently; we find out through trial and error what works and what doesn’t, and we need to have access to the right data metrics at the right time. (Going back to my days in the Knowledge Management world, designing systems for government agencies and multinational corporations, this heads in the direction of tacit knowledge – those deep-seated beliefs and nuggets of wisdom gained only from experience.)

Customer Service

Which leads us to the crux of the matter: customer service. 

In the digital realm customers can vary from internal users of a buying application to people across the globe hitting our website and interacting with us in some fashion.

Do you understand the data that your customers need? Do you understand that the way you use different terms – one in one part of the site that Team A built and one in another part of the site that Team G built – ah those silos – is very, very confusing to your users?

I think you’re getting the point. A taxonomy exposes all of the terms, all of the metrics, all of the data points and calculated fields. If you take it one step further you can categorize those into dimensions and measures, and eventually into data domains, the primary related chunks of data that supports the KPIs of the company, and thus, supports the growth of the company through outstanding customer service.

In Conclusion

You’ve no doubt been hearing the term “empathy” being used in UX discussions for quite a while now. You may have an understanding of its importance in core UX research and design work. 

I urge you to use that empathy to dig deeper into the fundamental data practices in the company and to understand how and why your users need the data that helps them do their jobs more efficiently and more effectively. Those are the two edges of the double-edged sword that can make or break a company. 

Do your best to ensure that your company thrives and provides value to the world.

To your continued success,

Jeff