Utilizing Wireframes For Product Designers, At Scale - Algrim.co

Utilizing Wireframes For Product Designers, At Scale - Algrim.co In this guide we’re going to go over what wireframes are, how to build them, best practices for what to include in them and best benefits of the practice with regards to team sizes that are more than 15 people. In general, the first thing we have to understand is that wireframes aren’t designs. They are intended to serve a purpose beyond communication setting, goal setting and calibrations of executive goals. As designers, you should know that inside of teams with more than 5 people, your job is mostly aligning communication and expectations of multiple parties involved in the progress of a product. That means, ensuring all stakeholders input and desired outcome of the end user is properly placed into the UX. Part of every process, regardless of how well a designer might believe they clearly understand the needs of all the stakeholders, they should still use wireframes to confirm those expectations. As a designer, consulting, it was always a benefit to go through the process of wireframes. Because you have to remember that as a designer, you need to gain the trust of the stakeholders that you clearly understand the desired outcomes. If you spend all of your time on the most beautiful visual designs up front, and they are incorrect, that’s not a great benefit to the company you are part of. Mostly because you spent a significant amount of time on something that didn’t have the proper foundation. “A wireframe is a visual representation of a user interface, stripped of any visual design or branding elements. It is used by UX Designers to define the priority of items on a screen and communicate what the items on that page should be based on user needs.” â€" The UX Review Think about building a home. If you attempt to the build the home while designing it, literally going through the construction efforts while you are trying to map out the architecture and design of the home â€" do you expect that the home will come out built well? Probably not. This is why I urge all UX/UI designers to use the wireframe process before placing any amount of time in cleanly polished visual designs or even prototypes. The Process Of Wireframes Best practices for building wireframes are pretty simple, understand your intent and goals as a product team. That means going through interviews with the stakeholders, including your customers, and writing down key points of interest. You should collect as many notes as you possibly can to reference once you begin building. If you have an existing product that you are improving upon, your wireframes will also include that part of it as well. The third stakeholder so to speak is the existing product and how you will use that as a point of reference. There are many tools on the market to build wireframes. In fact, you don’t really even need any tool other than what you are using for visual designs. That could be photoshop, Sketch or other. In reality, your goal should be to make something very low fidelity. That means ensuring that it doesn’t contain too much polish. Or else you’ll distract from the process of checking functionality and expectations of outcomes. In my opinion, wireframes can capture two very important area’s. It can allow everyone to understand what functionality exists on a page as well as understand how many steps or pages are required to accomplish a certain task by the end user. In this sense, it serves more of a User Experience or UX goal than anything else. Try to include as many details about functionality as you can. Wireframes are generally a series of boxes, which contain key indicators about functionality and steps. So when you are finished with your outline of the wireframe, writing specific notes about what the boxes will do and how it will do it (or even covering them in the wireframe itself) will be extremely valuable. Remember, you are going to be showing this to people who don’t have as much insight as you. This could be developers or other managers who may not have been inside as many of the interview sessions as you were. Your goal should be for those people on your team to clearly understand what’s being built, why it's being built, and have the ability to estimate the complexity of the product development investment involved. You can start wireframes as paper prototypes if you want. Drawing them either on a whiteboard or paper in realtime when you are working with Product Managers or maybe even directly with the CEO. Remember, this is a mental exercise, this isn’t something you are going to be perfect from the start. You should go into the process as if its a workshop. That means, understanding you will be booking multiple wireframe sessions with your teams. These sessions should include the interview process, the review process, and the finalization process before building visual designs or prototypes. Communicating Wireframes The best way to communicate wireframes is through the presentation or through click prototypes with the actual wireframes themselves. Tools like InvisionApp make this quite simple to do. You can add hot links to the blocks on the wireframe to allow yourself or others to know where a particular module will lead the end user. This is helpful in simply recalling how things will complete a loop. For instance, taking a forgot password user experience scenario, eventually, the user will end up where they started. Or maybe they’ll end up on the signed in the state of the web application. But you can articulate with the click prototypes, how a user will go from putting in their email to getting an email from the web application to clicking a link and eventually going into the signed in state. During your presentation, which usually takes about 15 minutes to present and then 15 to 30 minutes for review or collection of feedback, this click prototype can save you a lot of time. If you choose not to go that route, what you can do is set up the wireframe around particular user stories. Let's say you are trying to wireframe a very important piece of functionality in the web application but the actual UX is small, meaning that we’re attempting not to move many parts. You can write down your “As a user” stories directly into the wireframe itself, so that everyone can clearly understand what to benchmark the work against. If you fail to set up the before and after scenario with regards to the product outcomes, it will be much more difficult presenting your work to any number of your team and having them feel secure about proceeding to the next steps. By having all of this done at this point in the process, you are saving yourself a lot of time later on. When you get to the point where you are integrating the visual and brand design into the product designs that you are working on, most of the complicated decisions should have been discussed and decided upon . Using reference numbers is a great way to do this. You don’t want to block out the actual design. So if you can number each important element of the UI and then have a tear sheet which contains the user stories or functionality specifications, it can more clearly be referenced. Collecting Feedback The reason for low fidelity wireframes is so that everyone can stay on the same page with regards to the stage of feedback you are collecting. You want to ensure that all of the needs are met. This means, checking to ensure that functionality that is going to be built is the right functionality. Checking to ensure that the place where the functionality is going to exist is the correct place. And checking to ensure that everyone clearly understands the level of investment required in order to achieve what the wireframes are presenting, usually in the form of time or number of sprints that are planned out. It's not uncommon for the feedback to include reducing functionality or moving other components of the web or mobile application around to achieve the desired results. In fact, it's better if this is done during the wireframe process since its much easier to produce. If someone part of the team is unaware of this process and asks where the beautiful looking designs are, it's going to be your job to help them understand why wireframes are part of your process and what kind of feedback you are looking for. In general, here are some high-level reasons for why wireframes are of benefit and how you can explain this to teams: Expectation and Goal Setting: What are we building, how are we building it, what do we want to see, what don’t we want to see. Quality and Assurance Checking: Is this the place we intend to improve for our customers and users? Is there something we as a team or Company forgot to include as part of our goals? Communication: Developers can reference these as a way to understand where in their MVC (model/view/controller) or micro-services they will be making edits. Which helps them prevent technology debt as well as spending time where it's not necessary. What are “Good” Wireframes Wireframes have recently become more high fidelity than they have in the past. And I’m not exactly sure the reasoning behind it. The below screenshot shows a good mix of managing expectations of the end result and also ensuring that the work isn’t receiving too much upfront investment of time from the product designers point of view. It shows a healthy amount of thinking, which includes the collaboration you had received in the interview sessions, and execution. The below screenshot is also another fantastic example. It really defines the user flows as well as the process. Imagine yourself as the developer for a moment, won’t this help you really map out what you are about to build? Think back to our home builder example, having the blueprints before you begin the construction. In my opinion, both of these examples are great wireframes. They achieve exactly what we are talking about in this article, communication and expectation management. Visualizing ideas of the company, the teams and yourself. Conclusion Wireframes are absolutely part of the product and design process. They are the most critical form of communication. By having this clear communication it will save time. It provides a very moldable framework for which you can share ideas between yourself and executive leaders part of the Company. And can ensure that the highest quality output is being produced from a product management and design leadership point of view. As a product designer, your role may be to explain to the team the benefit of the process and reason for starting from low fidelity points of interest. But once you go through the next steps, which include visual design, prototyping and ultimately functioning prototypes, much quicker and easier than you could have before â€" you’ll gain the trust in the design process from more of your team and they’ll appreciate what wireframes have to offer them.