How to create a deliverable for a front-end engineer?

Question

This is a question about the development workflow of front end engineers. I am starting a project for a rather large site with lots of pages, each page has multiple steps, and it's very difficult to lay out all the content in a spreadsheet.

The content of each page will be delivered in a spreadsheet cell, and some pages have multiple variable section that are determined by user's preferences.

I was asked my opinion about how to structure the deliverable. I am wondering if there is a best practice out there for structuring this kind of deliverable? Because when you have a poorly structured deliverable it can be almost as mindnumbing as using pen-and-pencil to write code.

Do you have any tools, formats, practices for creating deliverables that are easy to work with?

Answer 1

It sounds like you are just doing the UI design and then giving it to the front-end engineers.

If that is correct, I would suggest that you see if you can do the rough html/css work to get the page to look as you want, and then they can go in and give it the functionality, but that way you have an idea what is possible.

You can do much of the work, then leave comments about trying to center something a bit better, for example.

I am not a big fan of just getting the design on paper or as an image, it would be easier to just get the html/css.

There are plenty of tools now that make css and html easy to do, even if you have the css inside the html, they can separate the two, but, it would be a huge help to the designers.

Just do one page, and give it to them, and then come back in a day or two and get feedback as to what their thoughts are, and how you can improve what you give them.

As you go through this process, after a while both groups will know what to expect and you can get the rest done quickly.

This is more of an agile methodology with the front-end engineers as your customers.

Answer 2

My suggestion would be mockups or wireframes for the pages. Mockups would be examples of the pages in various states while the wireframe is a detailed document of the structure of the page.

Answer 3

HTML and CSS is way too complicated for mockup use. I usually first create a requirement backlog for UI/functionalities as well (just a list of priorized reqs in Excel).

Especially for a large site development you should also have the process and data flow definitions done (UML or other way of description) to help you define the mentioned requirements.

Based on these you will know what kind of steps does the whole site funcionality need (i.e. pages) and what the page hierarchy and structure will be like. This way it's much easier to get a grasp of the whole thing.

After that we'll create fast wireframes and visualize the end result with fast mockups done as images with Photoshop or similar. These are absolutely vital in my experience as it helps the customer (and other stakeholders) to actually understand what is beind done. For this the html and css are simply too slow to run multiple iterations with.