Thanks to all who replied. Appreciate it. Assuming the designer is available most of the time, then it seems all agree here that:
1. Continuous communication between dev<-->business<-->designer is the key. 2. Making it right is an iterative approach. 3. Dev and Designer should speak the same "language" and understand each other's tools. 4. It is a team effort and cannot (should not) be done by exchanging screens via emails or so. (this just sounds as a normal Agile-ish style... why wouldn't it...) >From this perspective, if the designer is not a part of a team; but rather doing "once-off", "pay and go" stuff, the failure of UX seems to be imminent. In this situation options are: 1. Get a good designer on-board (might not be an available solution ATM). 2. Keep as close as possible to the original design while continuously updating the application. The option #2 can probably work only so much. On Nov 24, 12:51 pm, Daryl Manning <[email protected]> wrote: > I have to agree with Tim. Every project I've had go off the Rails where > design is an issue is because of the lack of inclusion of design at a stage > where it can inform functionality and design. Good design, like good dev, is > worth its weight in gold and the earlier the better. > > Daryl. > > > > > > > > On Wed, Nov 24, 2010 at 12:46 PM, Tim Lucas <[email protected]> wrote: > > On 24/11/2010, at 12:13 PM, Nicholas Faiz wrote: > > > > Using mockup tools like Balsamiq help a great deal, especially if your > > > customer is happy to use it to help visualize the application you're > > > building. The designer can also work from that too, but the customer > > > understands that the rougher looking app is modelled off a prototype. > > > It can increase confidence while waiting for the final design to be > > > implemented. > > > > There isn't a lot of work when refactoring a HTML design into Rails > > > helpers, etc.. I just make sure I *don't* use HAML for such projects > > > (I generally don't use HAML anyway), because it's foolish to rewrite > > > all of your HTML files into another format. > > > Great design is a process that goes all the way from idea to execution and > > back again, whether it's code or UI. Having HTML thrown over the fence isn't > > a process I'd recommend for Rails dev, I've been on a project or two like > > that and the end result was always terrible. > > > To the original question… > > > On 24/11/2010, at 11:07 AM, dnagir wrote: > > > > I am just wondering how you guys deal with working from having UI > > > design to the actual Rails implementation? > > > (e.g.: 37signals - Interface First) > > > 37signals have a designer working and collaborating on each team during > > build, not just at the start handing over photoshops or HTML. > > > Don't think interface *first* development, think interface *driven* > > development. > > > – tim > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rails-oceania%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
