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.
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.
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.
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 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.
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:
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.
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.
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.
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.
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.
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.
Here are a few examples of what your research may have uncovered:
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:
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.
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.
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.
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,