I strongly disagree. Of course I understand what you mean about proof-of-concept - your analogy of testing the engine is a good one. But think about wher the engine is to be fitted: if the UI is not well-specified, then the best engine in the world will only help you crash or blow things up faster.
you can't build good data structures until you have a clear idea of the information you want to gather and manipulate for the task you propose to solve, and often that involves going to other people in a specific market and asking them how they do things. I have lost count of the number of software packages I've looked at and asked 'why is X so awkward' only to receive the reply that it 'had to be that way' because of something on the backend. This is what happens when you build data structures that are half-adequate to the task at hand and then have to have other things shoehorned into them.
Well, funny enough, I am one of those guys who is equally comfortable doing mechanical, electrical and software engineering. In all cases, the "beautification" of the product happens after the underlying principles, data structures, circuit fundamentals, loads, thermal requirements, etc. are well understood and have gone through many prototyping and testing phases. I am not talking about minimum-viable-product stuff here.
Yes, if the goal is a minimum-viable-product type web solution, by all means, make it pretty and fake the rest until you see enough traction to figure out if there's a real business.
For nearly anything else, the internals need to be well understood before it makes sense to do anything else. I can't think of one mechanical design I've done where I spent a ton of time figuring out color, size, shape and location of buttons and knobs before fully understanding what needed to go inside the box, what the electronics was going to look like, communications protocols, power supply requirements, environmental requirements, etc.
So, yes, if I was going to design a car I'd start by selecting an engine, drive train and suspension components and then designing the of the vehicle rest around it. You'd fit artists concepts and renderings to the realities of the underlying mechanics. It then becomes an iterative process where you push and pull and make adjustments to both the artistic expression and the technical realities of the design in order to converge on a product that can be released.
Let me state the obvious: These analogies are all imperfect.
Comments
I strongly disagree. Of course I understand what you mean about proof-of-concept - your analogy of testing the engine is a good one. But think about wher the engine is to be fitted: if the UI is not well-specified, then the best engine in the world will only help you crash or blow things up faster.
you can't build good data structures until you have a clear idea of the information you want to gather and manipulate for the task you propose to solve, and often that involves going to other people in a specific market and asking them how they do things. I have lost count of the number of software packages I've looked at and asked 'why is X so awkward' only to receive the reply that it 'had to be that way' because of something on the backend. This is what happens when you build data structures that are half-adequate to the task at hand and then have to have other things shoehorned into them.
Well, funny enough, I am one of those guys who is equally comfortable doing mechanical, electrical and software engineering. In all cases, the "beautification" of the product happens after the underlying principles, data structures, circuit fundamentals, loads, thermal requirements, etc. are well understood and have gone through many prototyping and testing phases. I am not talking about minimum-viable-product stuff here.
Yes, if the goal is a minimum-viable-product type web solution, by all means, make it pretty and fake the rest until you see enough traction to figure out if there's a real business.
For nearly anything else, the internals need to be well understood before it makes sense to do anything else. I can't think of one mechanical design I've done where I spent a ton of time figuring out color, size, shape and location of buttons and knobs before fully understanding what needed to go inside the box, what the electronics was going to look like, communications protocols, power supply requirements, environmental requirements, etc.
So, yes, if I was going to design a car I'd start by selecting an engine, drive train and suspension components and then designing the of the vehicle rest around it. You'd fit artists concepts and renderings to the realities of the underlying mechanics. It then becomes an iterative process where you push and pull and make adjustments to both the artistic expression and the technical realities of the design in order to converge on a product that can be released.
Let me state the obvious: These analogies are all imperfect.
A good user experience isn't 'making it pretty' or 'beautification' – this is 2012, I thought this was repeated enough.