What Can Be Used to Document the User Interface?
Our team at UI Prep creates several products each yr and has discovered the best UX/UI documentation strategies for happy and productive teams. In this article I'll discuss our process; how we offset by writing pitches, a concept borrowed from Basecamp, and so create loftier fidelity designs in Figma with our own lightweight, organized method. These strategies tin can be practical to any website or production, big or small.
👉 Are you starting a new project or a redesign soon? Jump start your blueprint & documentation process with UI Prep's Pattern System. Acquire more about the pattern system here.
UX Documentation
Once the user enquiry and strategy for a new product is complete, it'southward time to first documenting the proposed UX concepts. Outset past dividing the production into 10-thirty major areas or workflows (due east.g. "dashboard" or "onboarding") depending on the scope of work. And then, i-by-i, write a pitch for each that explains why and how it should be created, with considerations for both design and development. The pitches should more often than not rely on writing to explain their concepts but also use wireframes to help others visualize the concepts.
Here at UI Prep, our team's UX documentation style is largely based on Basecamp's method of product evolution from their volume "Shape Up" which you tin find here for costless.
Pitch writing
Pitches are written documents, with some visual aids, that describe each area or major workflow within your production. These pitches are first used to present concepts to the entire squad to get buy-in, and are so used as a living library of all documentation needed to pattern and build the website or production. Each pitch will abound and evolve equally designers and developers weigh in and start using them.
Beneath is a pitch outline that tin be used for any website or product:
- Overview: Summary of the trouble or motivation behind the pitch, and the solution that is being suggested.
- Lay of the state: High level description of what volition exist designed/built. This often includes boosted context needed to empathize the finer details in the balance of the pitch. For example, in a pitch about settings, this section might describe how to access the settings page, where it lives in the product, and what the general layout looks like.
- Deep dive: Detailed explanation of an private expanse, characteristic, or event related to the solution. A pitch will likely have many "deep swoop" sections to cover everything that is needed. For example, in a pitch about settings, there might be a section nigh "notifications", "contour" "admin admission", "billing", ect..
- No-gos: Annihilation that is not within the scope of the pitch and should be avoided. It's helpful to record decisions, fifty-fifty when the respond was "no", for future reference and to reinforce boundaries for the team.
- Product designs: This is where links to the product designs can exist added. This department volition be left empty at kickoff.
Wireframing
Use low fidelity wireframes equally visual aids in your pitches to ameliorate communicate the concepts being described. Each wireframe should be specific to a department and show just what is required to communicate the concept. Showing too much detail at this stage might limit pattern exploration.
Our team prefers to create low fidelity wireframes in Whimsical then switch to Figma when we're ready to start mid/loftier fidelity design work.
Lay of the land wireframe
In the beginning of the pitch, it's of import to include a high level wireframe to show the general layout and how different pages/views/components relate to one another. This wireframe will provide needed context for the rest of the pitch. For example, a pitch about settings might show its access point, the layout of the page, and maybe some high-level functionality.
Deep dive wireframe
Virtually deep swoop sections should include a wireframe focused solely on the expanse, characteristic, or event beingness described in that section. These wireframes tin contain a single view or a series of views depending on what needs to be communicated. For example, a pitch nigh settings might do a deep dive on viewing/editing a user profile. This wireframe should show general layout and key actions like "save changes".
UI Documentation
Once some or all of the pitches have gotten buy-in from the squad, offset designing and documenting the product'southward UI. These two things should exist washed in tandem to make presenting and defending design decisions easier, even in the very beginning. Early UI documentation is likewise important for keeping the design file organized and ensuring all styles and components are used consistently from the start.
Our squad has experimented with many UI documentation methods and through trial and error, found the virtually effective ones. The most unique being our lightweight and organized approach to showing dissimilar workflows. This, accompanied with the detailed pitches, is the best way to document any project.
File structure
Creating and maintaining a well organized file makes a huge divergence in how well others will exist able to understand your designs. Someone unfamiliar with your file should exist able to apace navigate to a particular blueprint and empathise its purpose and behaviors with relative ease.
Organizing your file starts by creating pages, with clear names, for different design and documentation purposes. Below are example pages that tin can be used for any website or product:
- Main Components
- Style Documentation
- Global Components
- Major Expanse A
- Major Area B
- Major Area C
- Paradigm A
- Epitome B
- Image C
Major Areas
Major Area pages are the primary event. They contain nearly of the bodily design piece of work and are where both designers and developers will spend the majority of their fourth dimension. Each major area of a website or product (ie. "dashboard" or "invoices") should be given their ain folio and and then further broken down into smaller workflows or categories if needed. Everything related to these workflows and categories should exist grouped together and housed on a large frame. Each frame will contain a small number of case views, showing full designs, and and so a breakdown of each individual component.
For example, if you're designing an invoices page and want to evidence every filter land, document the filter states separately rather than showing an entire page view for each. This will brand the design file more focused and easier to maintain.
Example views
On the advisable frame, add a pocket-size number of case views showing the pattern layout, where all the components live and how they related to one anther. Included should exist at least 1 default view and a few other key views if needed. Additional key views are just needed if an event impacts the entire view or multiple components.
Component documentation
Next to the instance views, neatly document every component that is specific to that workflow or category. Every possible state and variant of these components should be constitute here with a short description explaining when, why, and how they are used. Documenting all component states straight next to their case views, rather than on a separate folio, makes them both easy to discover and easy to understand.
Global components
The Global Component page should display all components that are not tied to a specific workflow (e.thousand. buttons, inputs, avatars, ect.). Considering these components are so common and not-specific, they demand their own dedicated folio so they can be easily institute and referred to.
Each category of components should exist given its ain frame with a cursory description for each category and sub category within.
Pro tip: Sometimes when you make a holistic system of components (east.g. buttons), not every state or variant is used in the production designs. To salvage your developers time, document these component categories twice. First with all the possible states and variations that could exist used now or in the future. And second, with all u.s.a. and variants that are currently in employ. This is peculiarly helpful for younger websites/products as you lot don't want whatever precious development time beingness waisted on components that aren't needed. For instance, don't inquire your developers to build every possible tertiary button and their states when only one type is currently in use.
Way guide
Even though virtually your styles are accessible in Figma's blueprint console, information technology's nonetheless of import have a defended page where you lot tin can layout each style and add together boosted descriptions or context when needed. This is necessary because some styles tin not be captured in the mode console (e.g. when to use which corner radius), and some descriptions need to draw a family of styles, rather than a specific style (e.g. when to use any variant of an accent colour).
The Style page should be cleaved down into unlike frames, one for each category (e.g. color palette, elevations, corner radius). Each category should have a brief description, and each style, or family of styles, should accept their ain description.
Pro tip: Similar to global components, often when you create a holistic colour palette, not every color created volition actually be used in the production designs. Save your developers time by documenting the color palette twice. First, with all the possible colors that could be used now or in the hereafter. And second, with all the the colors that are currently in use. This way everyone will empathise the color palette logic and know exactly what colors are needed right now.
Epitome
The Paradigm pages are where designers and developers can visualize unabridged workflows. This type of documentation is so important because it helps teams stay on the same folio and volition often lead to UI questions and discoveries that would not otherwise come upwards.
Deciding which workflows to certificate with a prototype should be chosen carefully as they can brand your file boated and tin be time consuming to build and maintain. Select workflows who's functionality are cadre to the projection, or who'due south difficult to communicate with only static designs.
Bring it all together
One time the UI documentation is ready to exist shared, add information technology to the appropriate pitch with Figma links. This way, anyone reviewing a pitch can quickly navigate to the production fix designs and their related documentation.
How to link to a Figma frame in your pitch:
- Select a workflow frame inside of Figma
- Copy the URL
- Paste the URL into your pitch
Jump showtime your next project
Skip the hours (days?) needed to set your design file earlier you lot can showtime actually designing, with UI Prep's blueprint system. Information technology has all the components and styles you demand to go started and can be completely customized in less than 2 minutes.
Nosotros use it equally the starting point for every new project we piece of work on, and then tin you!
Learn more nearly the system
Preview the organization
Source: https://www.uiprep.com/blog/the-best-way-to-document-ux-ui-design
0 Response to "What Can Be Used to Document the User Interface?"
Post a Comment