Communicating an Existing Interface to a New Designer

When a new designer joins an existing project, the temptation to show the designer the interface rather than the spec is hard to resist, especially if the two are not very similar. The problem is that some information that was in the spec is very important to the designer, but will often not be communicated in an interface review.

So here are some things you need to remember to tell your designer if you’ve spared them the need to read your spec.

1. List actions that are not represented in the GUI: keyboard only and double-click only. Also list options that are available in context menus; they may want to move some of them to buttons.

2. Don’t explain just the what; explain the why and how, because they may have a better idea (they’re there to have a better idea).

3. List options that are only available if something else is selected (like a group of fields that is only editable if a check-box is marked). They may want to have the fields hidden instead of greyed-out, for example.

4. Tell them if you want messages to appear on the main window, rather than as a pop-up notice. For example, in registration forms validation errors are usually shown next to the fields. Designers need to know where to leave space, and to give you a design (like font and colour) for the messages themselves.

5. Tell them of status indications and how you’ve implemented them: colours, loaders, text, etc. For example, tell them how you show a connected or disconnected user in a chat application.

6. Show them all the states of graphic elements, like a button that looks like a text or an image, depending on work-flow.

7. Explain size limits on elements that have them. For example, a minimal width for a certain input field (because you always want the input to be fully visible) or a long bit of text that must fit in a menu.

8. If you’re providing a written review, don’t skimp on screen caps. Show the full window/pop-up but also focus in on important elements. Don’t be afraid to number elements on the screen cap and provide a numbered explanation for each, or use arrows and circles. Your review doesn’t need to be pretty.

9. List the buttons you were going to provide for each window and what they do. More importantly, list buttons that the designer probably expects to see but that you’ve removed. For example, if you have a pop-up where the closing X serves the role of a Cancel button, make that explicit, or you’ll get a design with an extra button.

10. Explain decisions that were based on limits that are specific to your technology, like a problem embedding PNGs.

11. Explain decisions that were based on accessibility, like a minimal font size to allow people with reduced eye-sight to work.

12. If your interface supports both left-to-right and right-to-left languages, ask for two designs. Don’t assume you can fully mirror a single design and have it work (though, honestly, it usually does).

13. If you have several windows that are a single window in different guises, make that clear.

14. Explain how navigation between different parts of the interface works at the moment (menu, tabs, Next/Previous buttons etc).

15. Point out elements that might change size mid-work, either automatically or because the user re-sized them.

16. Make it clear whether you want field labels outside all fields, or if place-holders can be used within all or some of the fields.

17. List elements that cannot be re-designed because they are not yours, like third-party controls and company logos.

18. Make it very clear if you want a pager, infinite scroll, a limit on the amount of data presented or anything of the sort.

19. Especially for e-commerce, provide a list of icons you’ll need, like Sale icons.

20. Be sure to show (or explain) all of the information that can be presented. For example, if a user can have seven different parameters, try not to show a user that has only two; you’ll get a very small interface.

21. Be nice and point out elements that you’re going to remove.

This entry was posted in Articles, Technical Writing and tagged , . Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s