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.
3
You mentioned 2 different use cases, each have a different answer
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.
1
Top to bottom for sure.
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.
1
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.