[UX] How to make UI design document at work #1
When we design UI at work, we can see lots of different documents. Many of UI designers are not interested in the documentation as much as they focus on their tools. Whatever we use the tool for UI design, I think the final consequence is the document, and it will be able to track the history and communicate with other collaboration workers. What we define in the document, and how we make the document is more important than others.
Here is my way to make my UI design document at work. As I said in the previous post, I am trying to define in my document including scenarios, polices, technical specifications not only wireframe as much as possible. Basically I think UI design document is a very good document to state them because it is one of the good intuitive documents in all work cycle like design, development, test, and distribution of the service.
1. Define service requirement
In this step, I list up the requirements. These include user requirement and provider requirement. Sometimes I am very confused of user requirement and provider requirement. We know this is always challenging for us, and we should understand provider’s side as well. The service provider should make their profit by their service, so even if some features can be cheating on the users and they make user scenarios worse or harder. We should make the priorities of the requirements and try to trade off between them. We may spend lots of time more than other steps to communicate with people in this step.
Plus, one of the important things is what we need to define the requirements and make them in the structure with MECE(mutually exclusive and collectively exhaustive) criteria. I have seen lots of requirement lists without keeping this side.
2. Concept of the service with wireframe or GUI
After you define and make the structure of the requirements, we make the key service concept with some visual consequences to communicate people like decision maker, counter-part workers like graphic designer, developer, tester, or so on. You can make the concept with just wireframe, or like a real graphic design.
This is an example of the wireframe service concept as below.
This is an example of the real graphic design service concept as below.
If you don’t have enough time to make the real graphic design service concept, or you should make lots of key concept pages, I recommend you to make them with just wireframe.
If you need to all related people like decision makers and others, I would rather make them with real graphic concept than wireframe because most of people hardly understand service concept with wireframe as far as I experienced, so consider your circumstance of the work.
Be sure that you don’t have to design all pages in this step. If you really need to discuss pages or want to share key UX concepts(e.g. UI layout, or design features), try this concept consequences to others. In the examples, I tried to discuss the media list page, and player page. Those were one of the main service features in my work.
3. Define the document guideline, and UI guidelines
This is very important to improve the productivity with other workers, but I rarely saw the document including this. In this step, I usually define two different aspects. One is the statement of the document itself, the other one is the reference of the wireframe or scenarios in the next step. You can just leave the comment the standard guidelines of Google or Apple, but I know their guidelines is very huge and you may not have to consider all of them sometimes. That’s why I quote some guidelines from them and re-define for my own document. Sometimes your developer environment is different, so you may define your own standard even if you want to keep their guidelines. For example, when I defined some UI controls in one of the Android project, I would like to keep the native behaviors or activities from Google guidelines, but I should define them with other ways because developers made them within a hybrid development environment. I should have consider normal web standards than Google native guidelines.
When you make the rule to state your document, you can save your time to explain all components to other workers in every time. Expression is what it is a way to state. For example, when I want to show the fixed text label in the service, I use the symbol like “”, so it can be distinguished by just my explanations in the scenarios or the text label. I also try to distinguish the pages sometimes, if I want to clear to discuss with someone like designer or developer. I used to use the purple circle included the text GUI as below in the page if I want to talk about the concept with graphic designers. I have been saved lots of time with this kind of skill to communicate with other workers for sure. I usually call this document syntax in my document.
The other one can surely save your work time if you define the guideline well. First of all, I think dialog guideline is very important because it is one of the most common and basic component to be interacted with users. There are lots of dialog types in the guidelines from Google or Apple, but sometimes you don’t have to consider all of them. I like to re-define some of them in my document and let other workers know them. This can also make other workers save their time if they already have the background of the guidelines well.
In this step, I define and give a different dialog name like “Two button selective message”, Two button and title selective message”, “Radio title message”, “One button alert message”, “One line toast message”, “One line dimmed toast message”. After then, I design the wireframe component and state the scenario with “Tow button selective message(“Something is doing something.”)”.
I also define in this step for the basic development or design guidelines. When I want to make the touch area clearly, I show the red-dot box on my wireframe. Sometimes you also need to consider some devices screen ratio, so in this case, I suggest how we define UI component position or how to apply this kind of flexible cases.
I especially consider one thing more in the android project. That is key actions like back key or menu key from android navigation bar. (You can see the bar in the image as above, you can see the triangle, circle, square in the black bar. That is the android navigation bar.) If you need to state this in all pages, you may be very tired of them, so I try to state basic guidelines about that. Of course, this is very hard to figure them out at the beginning step, so I prefer to define this things after I design some main wireframe and pages.
Ok. I think it’s better to talk about the rest of the step in the next post, #2. It must be so much long contents. Hopefully see you soon about that.
댓글
댓글 쓰기