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)

  • So your client didn't give product spec to you and refuses to do it? Commented Dec 13, 2013 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
    Commented Dec 13, 2013 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. Commented Dec 13, 2013 at 21:29

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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