Think UX Isn’t Crucial to Your Success? Think Again.

First, Consider this BI Definition

It’s generally accepted that Business Intelligence, or BI, is the practice of finding and using data to analyze a business, from quantitative measures like dollars and units, to qualitative measures like customer satisfaction.  This is accomplished in modern business through the use of technology that takes the data and spits out charts, reports, dashboards, visualizations, etc.  Of course that’s grossly simplified but you get the picture.

Forget for a moment that we haven’t yet defined what we want to do with this new intelligence but… 

Wait a second. 

How can we know what we’re looking for if we don’t have a goal, and we have no idea how we want to use our newfound intelligence?  That might be kind of backwards, wouldn’t you agree?

I teach a visual strategy design class and one of my slides talks about how good analytics and visualizations show you things you didn’t know you didn’t know.  You’ve no doubt heard that somewhere before.  I didn’t make it up, but it’s a pertinent statement to BI success and, it’s the perfect segue to UX.

So what’s this UX thing?

UX, or User Experience, is a discipline around which every BI project should be built.  It’s a foundation, a methodology, and a framework around and through which we discover information about our users and then craft a BI solution to serve the needs of those users.  Consider this illustration where UX = User Experience, UI = User Interface, and DV = Data Visualization:


UX informs the UI and DV.  The UI part that lies outside UX contains color, font choice, the specifics of interaction and other aspects of presentation.  The DV lives completely inside the UI and is your selection of charts, identified by the UX research, and placed in the logical order called for in a Use Case, Journey Map, or Persona, all of which come from the upfront UX work.

UX is two distinct sets of project work that fit into an overall Visual Strategy:  UX Research and UX Design.

  • UX Research
  • Interviews – from analysts to CEOs to IT
  • Data Discovery
  • Journey Mapping, Use Cases and Personas
  • Business objective
  • See what we have
  • See how we can use it to get better (stop losing money)
  • See how we can use it to make more money
  • See how we can use it to transform our business
  • UX Design
  • What do we need in our applications to serve our goals?
  • How do we ensure that each user type is satisfied?
  • Where do these things go?
  • What is a logical progression from Point A to Point B?
  • What’s the best, most intuitive workflow?
  • What saves my team time and makes them more efficient?
  • How much do we really need?
  • How many different ways do we provide a user to perform task XYZ?
  • How do we ensure that everyone “gets” it?
  • How do we incorporate microinteractions and feedback for the user?
  • What security measures do we need to account for?

Strategy Documents

These can be very informal but are great roadmaps to help get a project off the ground.  A typical document will outline the users to interview, a timeframe for completion, vendor contacts, key stakeholders – both business and IT, and the overall project goal, such as “We need system X to pull data from here and here and here, provide dashboards for upper management, deep-dive analytics capability to this group of analysts, and generate reports for all staff members.”  It should also list contingencies and possible blockers, much as you would identify in an Agile project.

We’re creating the scope of a project and the rules of engagement.

The UX research will uncover all the pieces of the puzzle in writing this starter document.  It will help you define what you need to do, who gets involved, and approximately how long it will take you to complete the project.  It will tell you where you must to go to gather the data needed, and it will most likely define the questions you begin asking.

A huge part of this research process is that last part – defining the questions you begin asking.  I interviewed a top executive out west last year who, after two hours in a room with me said that I’d been able to pull more out of him than anyone ever had before.  He said that the way I lead the session showed him that he was thinking too linearly and that he now had a better feeling for the data around him and how he could use it.

Those are the “AH-HA” moments we all look for.  Those are the win/win situations that propel us forward to the next insights.

Now We Begin UX Design

Now that we have our document in hand, our roadmap, our blueprint, and hopefully our team in place, we can begin the design work.  We have to account for further interview sessions, but we have what we need to get a good start.

Look back at that Venn diagram above.  See how a large part of the UI circle is inside the UX circle.  Yeah, that’s because in many ways there is an overlap of the two that can’t be denied.  While UI is mostly presentation layer, all the info you need to do that comes from the UX research and design.

And We Talk About Workflows

All of this work circles back to one thing and one thing only:

Did we build the right thing for the right person in a way that serves the purpose in the best way possible?

In other words, did we do our research right, and did we then turn that research into a usable and useful product for our customer/user to work with?

If our customer/user isn’t using the system, then we failed.  If our user starts at A and wants to get to C, but has to go through B, D, E, F, and R first, then we failed.  You think I’m kidding?  I’ve seen it!  I’ve seen workflows that involved printing a report, walking it to someone in another building, having that person print another report, hand it over, walk back, enter answers into another system, and on and on.

Users want to know essentially these three things:

  • Is it useful and relevant to me?
  • Will it be easy for me to use?
  • Does it make my job easier?

I’ll wrap this up with a tasty morsel for you to chew on.

Experience is about expectations.

If you don’t fulfill the user’s expectations in your BI tools/suite/application, then you need to tear it apart and rebuild it.  A satisfied user is your reward and starting every project with UX will get you there.

UX Design 101: Context in BI/Analytics Design

What’s the Context, Dude?

The first question I ask the stakeholder when starting any new UX research and design project is:

            “What’s the context?”

If that question can’t be answered, I know there’s more up-front work to be done before anything else happens.  When you ask this question, be prepared for a range of responses that swing from blank stares to, “I’ll send you the document”.

Without context, that expectation I hinted at in the last blog – Think UX Isn't Crucial...– means nothing.  Context gives the perspective for starting, and is a checkpoint for conclusion.

Examples:

  • We have a group of analysts who each search through 100GB of data a day looking for credit card fraud.  They have to generate detailed analytical documents with alerts for our regional managers that are delivered every Wednesday afternoon.
  • Credit card fraud analysts
  • Big Data
  • Weekly analysis reports
  • Regional managers
  • Alerting capability
  • Our technicians are having a very difficult time figuring out if the best course of action is repair or replace.  We need them to diagnose a problem in 2 minutes, and then get the correct advice so they can make the decision that best solves the problem while reducing our overhead.
  • Repair shop technicians
  • Parts inventory
  • Part wear and tear history
  • Predictive and prescriptive analytics
  • High degree of accuracy
  • Loss prevention
  • Our head of research travels 250 days a year.  We need a dashboard application that he can use on his smartphone to keep up with very specific results from lab work from our six international facilities.
  • Senior VP
  • Clinical trials
  • Web-based, mobile ready

Each of these context examples would now allow you to get started with a focus towards the best solution.  There’s more research to do, but now you know what research needs to be completed.

“Can I see your data dictionary?” is another up-front question that must be asked, especially when the “context” question falls flat.  And it’s no one fault.  Some shops are just farther along the curve than others, but it is inevitable if your UX project is going to succeed.

Context is User Specific First

I think we can all agree that the context for a dashboard supporting a CEO is different than the context for a dashboard or InfoApp supporting an inventory specialist.  Each of those roles has a specific job and each therefore views their world through different lenses, hence, different types of analytical views.

Now you can start your research with user interviews and this template might help you if it’s a new responsibility for you.  Ask for personas and ask for use cases.  Do your research, understand your collection of users, and build context sensitive dashboards and infoapps for them.  These can include both predictive and prescriptive analytics and can be directly tied to performance, optimization, and monetization.

Data Science and Context and UX - Oh My!

Big Data!  McKinsey&Company called Big Data the next frontier in an article from way back in the stone-ages of 2011 and they’ve continued to write and speak about it ever since.  At a recent UX conference I attended in NYC, I discovered that they have a full-blown UX practice area now.  That was unheard of even 5 years ago.

So, where you have big data, you might also have data scientists.  Why mention this here?  Because I’m gaining a deeper understanding of how intricately entwined the goals of data science and UX really are.

You, The Scientist

Yes that’s right.  You are indeed a data scientist when you put on the hat of UX Designer/Researcher because you’re looking for the big ideas as well as the nuances hidden in the pile.  When no one can define an accurate context for you, the data, combined with a few other very specific lines of questioning, maybe even with the customer data scientist(s), can get you headed in the right direction.

You may discover several different contexts as you begin to dig.  Some will overlap, but with a little more work you can define each so that all users understand.  Consider that those overlaps are what form the workflow for the organization or department and all lead directly up to goals and performance.

Now It’s Time for a Review

Here are a few examples of what your research may have uncovered:

  • Total Retail Sales for the US seems to be important to the SVP of Sales
  • Sell-through seems to be important to the Regional Sales Managers
  • % of on-time deliveries seems to be important to the Shipping Clerk

Each is a context defined from your data research combined with your interview responses and now that you have both, you can define the context for an infoapp or dashboard.

Here’s a Quick Example

The Regional Sales Manager from above needs to know the sell-through so that she can keep on top of store inventories in her region.  When armed with this KPI and other data points you’ve discovered in your research, you can now design an annotated wireframe to take back to her for discussions and finalization.

You sit down with her and show what you’ve designed based on the interview.  She will do the following:

  • Tell you that you’re right on target and sign off on the design
  • Get other ideas based on what you’ve shown and ask you to include additional charts, KPIs, or summary reports
  • Tell you that you might have misunderstood something and what she really meant was…
  • Tell you that you’ve missed the mark entirely and must start over

While point 3 is unlikely if you’re using a good interview template, it is possible so just be aware and move on positively from there.

Big Picture Wrap-Up

Can you see now how the differing contexts within a project fit together to form the bigger picture?  Like pieces in a jigsaw puzzle, when you see each individually, you’re at a very specific and granular level of context, and when you put them all together, you articulate the overlying context that identifies the company goal, vision, and mission.

UX in the Trenches

Ah UX, that misunderstood, misrepresented, and down right mystical practice that has some still scratching their heads.

In the digital world - where I tend to do most of my work - user experience (UX) design is a combination of research, prototyping, and design.  It's part Information Architecture, part user interface design, part independent work and part collaboration, and a lot of ideation and iteration that all starts with the grandaddy of UX methodologies, RESEARCH.

When we're out in the trenches, us UXers are most at home.  We're digging around in other peoples things, in their minds, and in their habits.  We can be thought of as business anthropologists because we're trying to discover and identify specific user societies within a company, and determine to the best of our abilities, just what it is they do when they do their work.

We work closely with stakeholders and business owners, users, SMEs, data people, developers, and designers.  We cross the bridge between design and development, ensuring that each side understands the others needs and language.  

Business Growth

Our primary function and goal is to support a business's growth, and we accomplish this when we bring together all the moving parts of a website or enterprise application project.  Our focus is the user, whether they're internal knowledge workers, or external customers.

We scope the project, we manage the progress in collaborative research and design sprints, we document it all - loosely as is taught in Lean UX - and we do all of this to the beat of the project expectations as set and written by us and the stakeholders.

And when we do all of this, we create an atmosphere where our users can accomplish their goals.  If you're a student of Alan Cooper's work, you know this as Goal Directed design and I highly recommend his seminal work on interaction design, About Face.

To your success,

Jeff