Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
FLASH SALE: Save $500! Use code FLASH2026 at checkout until Feb 14th at 11:59PM ET. Register Now!
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Starting Up

Please share your suggestions on information you gather from the end-user before designing a Qlikview document. Questions asked? Issues considered, etc.

1 Solution

Accepted Solutions
johnw
Champion III
Champion III

To be honest, I typically don't gather information first. I take what little they've told me, combine it with my general knowledge of the business (20 years), and create a rough prototype. We THEN discuss what they really need using the prototype as a talking point. Sometimes this is just done in email. Sometimes it is done in a meeting. Questions asked and issues considered are very specific to the data and how they'll be using it, so wouldn't be of general use.

But I can still take a stab at this...

What is the scope of the data? What data will and will not be included? You don't want a giant monolith with an entire data warehouse of information on every possible topic relevant to the business as a whole. But you also want to have enough supporting data that people who want to dig in a little aren't forced to open up other applications to do so. So you need a clear idea of what they need to know, and what they don't need to know.

Who is the primary audience? How sophisticated are they at data analysis? Do they want complicated, interactive charts with numerous options, box and whisker plots, and that sort of thing? Or do they just want a simple dashboard that gives them the basic information they need at a glance? Or is there a combination of users that have different needs for the data? If a combination, should the application perhaps be changed into two applications? Or is it better to leave it together, but design different tabs for different groups of users?

How will they be using the data? What decisions will they be making based on the data?

What sort of screen resolutions are they running? At our shop, we design for the lowest screen resolution in common use at our company. But if you have a group of users that all have huge monitors, for instance, you could take advantage of the additional space. Or if they want to see the data on their iPad, that's a whole different can of worms.

How timely does the data need to be? Daily load? Hourly load? Real time updates?

Do they need a historical view of the data, such as how something looked yesterday, or do they only need to see the current state of the business?

Do they need any predictive modeling? Or if predictions are even necessary, are they happy to extrapolate themselves from a displayed history?

View solution in original post

4 Replies
johnw
Champion III
Champion III

To be honest, I typically don't gather information first. I take what little they've told me, combine it with my general knowledge of the business (20 years), and create a rough prototype. We THEN discuss what they really need using the prototype as a talking point. Sometimes this is just done in email. Sometimes it is done in a meeting. Questions asked and issues considered are very specific to the data and how they'll be using it, so wouldn't be of general use.

But I can still take a stab at this...

What is the scope of the data? What data will and will not be included? You don't want a giant monolith with an entire data warehouse of information on every possible topic relevant to the business as a whole. But you also want to have enough supporting data that people who want to dig in a little aren't forced to open up other applications to do so. So you need a clear idea of what they need to know, and what they don't need to know.

Who is the primary audience? How sophisticated are they at data analysis? Do they want complicated, interactive charts with numerous options, box and whisker plots, and that sort of thing? Or do they just want a simple dashboard that gives them the basic information they need at a glance? Or is there a combination of users that have different needs for the data? If a combination, should the application perhaps be changed into two applications? Or is it better to leave it together, but design different tabs for different groups of users?

How will they be using the data? What decisions will they be making based on the data?

What sort of screen resolutions are they running? At our shop, we design for the lowest screen resolution in common use at our company. But if you have a group of users that all have huge monitors, for instance, you could take advantage of the additional space. Or if they want to see the data on their iPad, that's a whole different can of worms.

How timely does the data need to be? Daily load? Hourly load? Real time updates?

Do they need a historical view of the data, such as how something looked yesterday, or do they only need to see the current state of the business?

Do they need any predictive modeling? Or if predictions are even necessary, are they happy to extrapolate themselves from a displayed history?

disqr_rm
Partner - Specialist III
Partner - Specialist III

Great response, John.

Not applicable
Author

I always start by looking at what they are trying to achieve, then add the technology Smile

Regards,

Gordon

Not applicable
Author

Thanks John. This was what I really needed and quite helpful.