While the advice isn’t necessarily rails specific, I think the design process he uses is great and I’ve broken it down here to remind myself later.
Step 1: Design the model
Ryan starts with a model. Notice I didn’t say data model—just model. These are the words and abstractions he uses to talk about the system.
If you are interviewing your customer you might ask them to tell you about the system, explain what it does. And as you are going through this you’ll start to catch the terms and words (abstractions) they use to describe the system. This becomes your domain language from which your ubiquitous language (Domain Driven Design) can flow.
Step 2: Screens
Ryan uses the Restful design approach as a pattern for screens.
Basically he says each element of our data model is probably going to require some CRUD like functionality and builds screens around that. This is how Rails works with MVC out of the box.
That doesn’t mean that all your screen need to be named insert, update and delete.
Just that you are probably going to want to work with these abstractions in your model some way, and Rails, which is built on Rest, gives you a good start point to think about that.
Step 3: Designs
With the screen layout defined, Ryan then takes one of these screens (the show screen) and uses paper and pen to figure out what the design of these screen might look like.
Step 4: HTML/CSS
With the paper prototypes, Ryan then moves quickly into HTML and CSS. Here he just hardcodes what he sees on the paper, gets something up quickly, and hands it to the developer.
His goal here is feedback. He wants to take the theory and make it concrete as soon as possible to see if the model and design are going to work. It’s not about the pretty pixels. It’s about form.
After Ryan hands this off to the developer, he will take screen shots and start playing with the look and feel inside Photoshop.
Step 5: Live code.
Now we get to make it real. Here Ryan and his developer partner leverage rails to define their models and controllers.
Something nice about Rails is it has a nice separation of backend services (*.rb files) from the look and feel or view (*.erb files). This let’s developers do backend stuff while designers can work on front end.
So there you have it. One way to build a rails app. Once you get good at this Ryan says you can start cranking stuff out that your customers can play with in the order of 2-3 days which is great for rapid development.
This is a great video and I recommend watching it if you want more insight into how to go from concept to idea quickly using Rails.
Thank you Ryan Singer and 37Signals for the great video.