Design Requirements
This page will serve as a requirements document of sorts for any designer who works on the website, so as to avoid all the issues that I described in our open letter.
When designing things with users in mind, it's important to have the customer's interests properly represented. If a design is put forth for the benefit of the user and many users do not like it, then the effort is mostly wasted.
Be sure to continuously ask for brief feedback - not just from the team. Not just from the team leaders. Ask random people. Could your mom use your phone app? Maybe your Computer Science friends can navigate the site...what about your friends who are Math or Philosophy majors? Would your site be easy to use for a friend from a foreign country? Ask your boyfriend if he reads pop-up instructions or if he skips them. Then ask your ex-boyfriend. Show your girlfriend three different renders and have her rank them. Ask her cousin to do the same. If you can somehow communicate with your dog..., well hopefully the sentiment is clear.
This part is very important when picking a final design, but even more so when wireframing and storyboarding. If the user has to click 10 times to get a certain action done, perhaps the design needs to be reconsidered. A small suggestion for instance: We currently have 17 questions set up for the HackRU application - no matter how you slice and dice it, scroll window or no scroll window, that is a lot of questions. Perhaps it's for the better to cut out some of them.
Wireframing is an important part of the design process, as it essentially tells both the other designers and the developers the what and where of each element. Refer to this article for more information.
A good example of a wireframe is one completed by David Chen - this link will lead you to some useful Adobe Illustrator Files.
A simple, watered down example of this process:
Our devs will look at this and start thinking about how to structure the app, maybe something like the following:
Now they may try to add more specific things to this starting diagram.
For example, the end-goal for Front-End is to follow the Flux pattern instead of regular MVC:
So, the model becomes a bit more nuanced, and we may end up with something like this:
The team can make better design/development decisions when there is more information available firsthand. For the example below, there are already some small thematic elements being explored, such as rounded corner buttons and certain font-sizes. Now things like CSS classes and HTML annotations can be approximated if not determined.
Wireframing, no matter how intricate or simple it's done, is important to tell us the what and where of the visual elements. You can think of the resulting app design/architecture as the developer-handled how. The when needs to be detailed through the storyboarding process. Think of a storyboard as a finite state machine diagram for views.
A storyboard can be drawn out on several levels. At an app level, it is more effective to group views together into a definite app state. This could be something like grouping the Status Window, Travel Form, and the User Info Prompts into one state of User View.
Here is an example of storyboarding for a calculator app, from Rutgers University's Software Methodology Lectures:
In the example above, it is clear what button/action leads to a different state.
A storyboard can also be drawn out at a lower, component-based level, like what I did for our current LoginForm:
In this FSM, the boxes represent triggered actions, either by some button, or some user action. Many of the ovals here would be in the same view group - the LoginForm does not change dramatically between a "not logged in" state and a "forgot password" state, other than what would be in the alert box.
A proper, robust, and unambiguous storyboard contains wireframes combined with storyboarding connections. Again, I look to the lecture notes for an example:
With this in place, there can be no confusion. An "operator" button will take us from state 1 to state 3, the "C" button takes us from any state to state 1.
Storyboarding should not be new to anybody: It is very similar to a flowchart for a function or an event map for a story or game. It is almost certain the reader has done something like this in some capacity already.
The visual design mockup should actually be one of the later things to provide, as these are mostly development independent. At this point, the structure will already have been laid out, if not already in the process of implementation. The visual mockup (the super-fancy Adobe Illustrator File or static html page) only dictates what each part of the structure should look like. For instance, while the wireframe and storyboard would take care of the layout of the sidebar, the mockup could be examined to determine what style the sidebar should be:
Or to use more concrete examples:
The compare and contrast process for different renders should be one of the last tasks to complete. Remember that feedback throughout the entire design process is the key to shaping the final product.
In my opinion, making thematic choices is the easiest part, because changing things like colors, gradients, timings, and fonts are simple CSS changes, and they are even simpler with Sass. Hence, these can be changed on demand. It becomes the front-end developers' responsibility to make sure everything looks the same across different devices, window sizes, and browsers (known as website responsiveness - we use Bootstrap for that).
Having a guide like this is a good idea for documentation purposes, and will make the workload a lot easier in the future. Some designers may put the theme/style guide first: but that's usually because it contains established motifs or themes that must be kept consistent across all products, as would be the case in commercial design.
David Chen even added palettes and color schemes to the marketing repo:
Please refer to his work for a good sense of organized design maintenance.