In my view you must think in terms of data models / data representation first. Then you move on to CRUD. At that point you might move into some of the functionality above CRUD and other app mechanics (for example: login, authorization, verification, support interaction, etc.). At this stage, if we are talking about a web project, the UI doesn't need to look any prettier than a Craig's List page.
Once that reaches flight altitude (meaning, that the basics are working) the UI can become the focus.
This becomes particularly true when you consider multi-platform applications. Say you have an app that needs to run on the web, mobile-web, as well as various phones and tablets. If the UI is first, which one? They are bound to be different. If you focus on the UI first you might do things that skew the model to suit a particular platform.
I you believe in MVC then you ought to be able to separate the three through specifications and marry them once each has reached a certain level of compliance with said specifications. Of course, there are difference that contrast a solo developer/designer vs. a multi-person team.
I want to see the engine sputter, backfire and pop before I try to optimize anything and make it pretty (UI).
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.
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.
However, you're still going to initially design your application based on a single interface, whether that be an iphone, browser, or tablet. While the implementations will differ, the UX between all the clients should be consistent.
In the article, I put UI ahead of CRUD because I believe the UI is closer to the UX and better helps you achieve your UX. And by UI, I mean a very very simple user interface. Hold back your creative artsy mind and just make sure you have the actions on the page.
thanks for the comment.
Leave the data model alone, and stop thinking about the UI. Do some real design.
Consider a simple example - registering a user account.
Assume the product vision statement calls for a thick client desktop application that synchronises data to other desktop clients via a server. To use the sync service you need an account. On the client, you put up a form that asks the user for a user name and password. Easy. What happens when the call to the server is made to register that account?
Does the UI just lock up until the call returns? Does the UI remain responsive? Does a responsive UI allow the user to cancel the request? Is the technology chosen to build this thing even capable of asynchronous service calls?
When the data is sent over the wire, how is it protected? When it hits the server, how and where is the password stored? Is the request logged? Will server logs be of use to anyone? What error conditions are checked on the server, what corresponding messages are sent back to the client, and how are these communicated to the client? Is there a retry button the user can hit when it bombs? Should the client use a database/temporal cache/config file to store the user name and password in case the server is unreachable?
That was a very simple use case. [Edit] My point is that those questions demonstrate that the data model as well as the UI might radically change based on other design decisions you should be making first. To answer those questions you need to do some design work.
Design work means analysis to get business, user, system, and operational requirements.
Then you need to think about availability, backup and recovery, capacity, communications, deployment, end user support, data migration, monitoring, performance, pilot program, security, system support.
It's called an architecture.
[Second edit] The agile police is probably going to jump on me for what I wrote. Let me pre-empt that by adding that even little web apps have what may appear to be very simple use cases that can bite you in the ass.
This can be done in writing on a piece of paper.
https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...
thanks!
Edit: oddly, Readability works fine.
Obviously if you're working on an API, this doesn't apply - but you'd be surprised at how fast the hacking sprint can get when you know exactly where to plug your code into.
I guess there are different schools.
An exception to this could be when you just need to get something up and running for morale reasons, so you can begin iteration. (Although in that case I would still argue that focusing on the UX isn't critical)
My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe."
Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.
With that said, I do feel like teams of pure programmers have a tendency to overlook the UX in favor of diving right into the code. The article is a great reminder that it takes more than wonderful code to solve a problem. In fact, the less code the better.
Yet, somehow, I've manage to consistently hack successful things.
My advice: Avoid linkbait articles like this, and instead spend the time actually building something. Really, it truly is that simple: Build something. In any order. With any technology.
tl;dr: hypothetical use case, data model, CRUD, UI, test for results.
