#### Preamble

As a psychologist, I would sometimes get called in for HCI design work. It all seemed like common sense, nothing out of the blue, and I wondered why the Programmers couldn’t do it themselves. I got my answer when I joined the data analytics lab. A design only becomes common sense, when the user requirements are captured accurately including their workflow and preferences. This is something I did not fully appreciate until I became a full time engineer. We have limited time to pay attention to the customer, as we have our hands full just trying to get system A to talk to system B. I also started to notice tensions in the design and engineering team that I had glossed over as a junior engineer. Here I note some of my experiences working on both sides of the camp.

#### Designer’s perspective

The designer cannot accept an engineering product that is trying to find a nail to fit the hammer. Often the engineering team produces something that they are excited about or want to develop, without listening properly to the customer’s requirements.

However the customer has clearly stated that this is not a priority, and
want something else which is not being done. How do you expect me to go
back to them with this?

#### Engineer’s perspective

This module is going to be useful. And I know a cool way to implement this.

….Later at the meeting…

How do you(designer) know they(customer) don't want this?
They didn't say they didn't want it did they?

… 2 hours later …

We've already built something. It's not that easy to change as you
think. Adding a new feature in the dashboard is not like adding a square
box in the powerpoint slide.

#### Conclusion

Ideally, design should come first. But it’s not always easy to know what your engineering team is capable of until you get deep into the project. Most web engineers are stitching open-source libraries and using ready-made UI plugins (no shame in that). The designer should ask what libraries the engineer is familiar with, or is interested in trying, and draw/conceptualise something from stitching together components from the library’s example gallery. This is essentially what the engineer would be doing - searching through the example gallery for the closest sample code that fits the design drawn.

Also the front-end can be misleading. For rapid prototyping, we engineers can get lazy cos we know the whole design might be scraped. What you see on the screen is a mashing together of someone else’s code, and depending on the skill level of the engineer, it can be easily modifiable, or a big fugly mess beneath.