Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm designing a number result tables for a new product. In order to design anything worth my and my client's time and money, I need to know and verify what the data that I'm designing with is. Instead I'm expected to design "on assumption" and I'm refusing to.

I strongly believe that I'm right, but am I? Does anyone have any link that I can forward to make my case IF I'm correct?

Any leads would be greatly appreciated. (if anyone needs to delete this post, no problem, it may be misplaced in this forum)

share|improve this question
    
So your client didn't give product spec to you and refuses to do it? –  Alexey Kolchenko Dec 13 '13 at 20:19
    
Basically. There is a basic misunderstanding of the process. The client has given me a spec with datapoints that haven't been confirmed with the API, meaning that they are assuming that the data is present, when it may not be. (The API data is provided by a third party.) –  Ana Dec 13 '13 at 21:05
1  
Then you could explore API, align clients' spec with API and find possible issues and inform client. Sometimes clients have no clear understanding or don't know the constraints of third part components. This is your role as analyst. When spec is aligned you could create stub (fake data) and use it in design process without actual third part usage. –  Alexey Kolchenko Dec 13 '13 at 21:29
add comment

2 Answers

I've had experience on both sides of this.

Client's Perspective

In my case, the client was developing an engineering product. The thought process was in terms of reusable components. If you look at popular CSS frameworks like Bootstrap or Foundation, you'll see a set of UI components with a consistent theme. The requests from the client were in terms of "can you make us a generic table?" They were asking for their own theme for a framework. Their development process was iterative, which meant all of the requirements were not available at the start. They knew many pages would have tables, but did not know of what the system would generate for data that goes into the tables.

Designer's Perspective

The designers wanted to know the width and height of the table, how many columns, and the longest length of characters available in each column. They were looking for constraints to ensure the integrity of the design. They wanted to avoid things like this. This is where the contention can happen, since these answers would be uncovered later in the development process. However, if design waits until the end it can become an afterthought.

My Takeaway

I see this more prominent in product design where software engineers are looking for reusable components and designers are looking for consistency despite uncertainty. I've had success in using the iterative process and refining the design continuously as more information becomes available. Not knowing your client or project, my recommendation is to consider making the case for what information you need to meet the design goals so as more information becomes available the design can be refined and matured.

share|improve this answer
add comment

I wasn't able to find a definitive link however, bringing to light web accessibility may help your client provide the data you need to design the data-table.

You could also use this to hold a small design studio or wireframe session to work with the client and draw up what they want.

In past occurrences if one of my clients was unable to provide data I would cover possible conflicts with accessibility which led into a small design studio or creating a wireframe within balsamiq. Wireframes take around 10-20 mins to mockup and are easier to address design conflicts and see what the client is looking for.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.