I'm an interface designer and now I'm working with a team of programmers to develop a new CMS for a heavy media site.

As I've started developing a specification list for a prototype it turned out a very big one. I do realize now that the client-side will be JS heavy, with lots of DnD and other "cool designer stuff". The CMS will even include a small project management system for its users, nothing big like Basecamp, but with a live feed of comments etc.

The problem is the the team has now separated. Someone is proposing the existing backend solution used in other CMS, someone is proposing to rewrite everything from scratch. The point to keep the code is that it is faster, the point to rewrite is to make it better for the proposed design (include Node.js and other stuff I don't actually get).

The question is — can the UI specs influence back-end? The guys that propose to use the existing solution did everything with the Yii framework (as far as I know), and they say that everything on server is not affected by this "interface coolness". Others say that it does, that even autosave can't work without server load.

If the project was architected properly, all communication between the UI and the server should be a clearly-defined API of REST, AJAX and/or web services, so no, it shouldn't matter what UI technology you use, so long as it adequately meets the UI needs.
–
Robert HarveyDec 12 '12 at 23:25

This isn't top-down vs. bottom-up, this is externals vs. internals. Externals are (or should be) the natural expression of product requirements, so they should drive the design discussion. It's the reason that Product Managers/Owners often do UI mockups to help describe the functionality they want built.
–
Ross PattersonJan 12 '13 at 14:42

3 Answers
3

First, I want to note that the server-side framework is irrelevant if the data is exposed through a REST API because data will most likely be fetched through AJAX requests anyway.

Top-Down if designing new interfaces:

APIs are usually defined based on real-world use cases. They should only expose a limited number of routes for accessing data, and those routed should be defined by how they will be used. In the case of adding new functionality, it would probably be easiest to mock up the general layout to get a better idea how it will be used.

Bottom-Up for existing interfaces:

I don't think I need to go into extensive detail about how dumb it would be to design all of the existing functionality if you already have a working implementation. There are plenty of articles online and real-world examples that prove that the time/energy investment if a full re-write usually isn't worth it (ex PERL 6).

Even if the back-end devs decide to use a different framework, it's much easier to adapt existing implementations to a new platform/framework/language than it is to draft new ones from scratch. Don't forget to consider the significant time investment that went into battle testing the existing implementations.

The key to adapting the existing code is to identify and rip out the unnecessary parts. Once that's done, how can the UI be designed to incorporate the existing functionality.

Thank you very much for the feedback, I really appreciate it. The case is that the interface works and behaves completely different than in the existing solution. The existing one doesn't have any of the proposed features. The problem for me is to figure out how the existing one can be stripped apart to adapt for these new features, I still talking and discussing it with the engineers.
–
george_zakharovDec 13 '12 at 9:27

The UI, or UX is a lot closer to the user and what the user expects of the application. How the user works with the application should determine what is required from the backend.

In a way you could see a UX design as a backend challenge, it's up to the backend folks to communicate if they can or can not deliver.

With their imposed constraints the UX design may have to do concessions and adapt. But always try go for the best possible solution and lower the bar only when needed. Do not speculate about what the backend may find too hard or not. Let them tell you.

If they have significant existing code already on the shelve, just talk your designs through with them and see what they can support. Always go back to your customer/stakeholders though for decisions, even if some compromise on usability can save a bit of work it may not be what they want. They might insist on the more expensive path if they see value in it.

Thank you very much for your answer. Everything you said is very profound and I still need some time to figure everything out. "Do not speculate about what the backend may find too hard or not. Let them tell you." — well, that's practically what the developers who want to build from scratch told me. It really rings a bell. Well now I'm still talking to everyone and trying to figure out if there is any possibility to use the existing solution. I feel that building from top is better, but I'm trying to hear everyone's opinion, especially when I'm not that qualified.
–
george_zakharovDec 13 '12 at 9:31

The ideal design would be one where frontend and backend are so completely structurally independent that each team can focus on its own strengths without necessarily bending to appease the other. That's the goal, but it typically isn't realistic.

For the rest of us in the real world, here's your rule-of-thumb to help you prioritize appropriately: start with what matters most. If performance is your key driving feature, start with performance. If UI effectiveness is the most important feature, start with the UI.

The decisions that matter most should be made with all possible options open to you. All other decisions will then be made in the context of these "important" decisions.