How We Roll Our Design Process

Processes are a part of the everyday life of UX designers, and honestly, it's a struggle before we can find the best method or tool that fits our needs for the moment. Even today, with so much content on how to make a meaningful and pleasant design, we end up getting a little lost amidst so many methodologies and opinions coming from all over the world.After diving deeply into studies, research, and testing, our team started to better visualize and consolidate our own process. This was an excellent fit for our profile, which brought us successful results, making design indispensable for a software consultancy. It not only added quality to our products but also has become a key part of building and growing clients’ confidence.As we believe that sharing knowledge is one of the best ways to learn and collaborate with the community’s progress, we decided to tell a little bit about how our design process has been done. It is worthy to mention that every tool addressed in this document has been vastly explored and tested by our team.Below you can find a step by step that we crafted, it works for a lot of different scenarios but it is constantly improving based on our ongoing experiences. <figure class="kg-card kg-image-card"><img src="https://s3.amazonaws.com/vintasoftware-wagtail-ghost/blog/2020/03/process-icons.png" class="kg-image"></figure><hr><h2 id="1-briefing">1. Briefing</h2>We always start our journey with studies on the clients’ needs and the purpose of creating or improving their product, outlining goals for a solution. A briefing usually happens during our weekly design sync with the client. Still depending on the feature, it can also be done asynchronously through our regular comm channels, <a href="https://asana.com/">Asana</a> or <a href="https://slack.com/">Slack</a>. As a way to start mapping the initial scenario, we start answering some essential questions:<ul><li>Why does the product need this feature?</li><li>What user needs are behind it?</li><li>What business needs are behind it?</li><li>What will be the impact on the current user experience?</li><li>How much effort is likely to be involved?</li><li>What are the KPIs and definition of success for this feature?</li><li>What metrics can we obtain to guide us through this improvement?</li></ul>It is extremely important to have everything documented so goals are clear and available to everyone. For keeping track we currently use Asana, where we also update the whole sprint progress. Once the major questions are answered clearly for everyone, we are ready to go!<h2 id="2-discovery-research">2. Discovery & Research</h2>This is the phase where we learn as much as we can about the feature's context. For such, we hit the internet, talk to users, do the benchmark, and analyze general data. Here are some of the methods we generally use:Benchmark - Understanding what already exists in the market is fundamental to build a reliable interface. We go after the best products and evaluate their failures and successes.User interview - Knowing users, their pain points, and opinions about the product is a great way to learn about the context we are dealing with. As our customers are from other countries, we usually do these interviews remotely by video call. <a href="https://hangouts.google.com/">Google Hangouts</a> and <a href="https://lookback.io/">Lookback</a> have been useful tools.Shadowing - Sometimes this method can also be a great pick, since observing users’ behavior side-by-side while using the current product helps us to realize what can be improved in the interface.Metrics and Data analysis - We have the habit of studying and researching thoroughly. Analyzing metrics of all types with the dev team and knowing the product ins and outs gives us great insights when tweaking the user experience.<h2 id="3-information-architecture">3. Information Architecture</h2>After understanding the feature in-depth, time has come to build a visual representation of its infrastructure, which includes hierarchy, navigation, content, behaviors, and flows. Granularity is adjusted to the scope and relevance of the feature. By doing so, stakeholders and the design team can better envision the magnitude of what will be produced.Flowcharts - We usually organize our ideas in flowcharts to better outline the user journey, workflow, or sitemap. <a href="https://whimsical.com/">Whimsical</a> has been really helpful when building these flows.Tech viability - Because we strive for feasible solutions, we always check the feature viability with the dev team. This is extremely important so we avoid future back and forth.Wireframes and Lo-fi prototypes - Our golden standard for complex features, is to build wireframes and/or low-fidelity prototypes followed by internal navigation tests. It is the optimal artifact to get a fruitful design critique.Having established the body of our solution, it’s a suitable moment to present the solution proposal and effort estimate, reevaluating its priority accordingly between designers, team managers, and clients on the upcoming design sync.[newsletter widget]<h2 id="4-ui-design">4. UI design</h2>At this point, the flow has been validated, and refinement of the screens begins. All behaviors and ideas are translated into a high-fidelity interface, adding colors and elements of brand identity, bringing the feature closer to the live product. We use <a href="https://www.sketch.com/">Sketch App</a> for this polishing.This is usually the most long-lasting phase of our design process, where all of our efforts are put together to achieve a fitting interface, hence all the components we build are based on solid research, are purposeful, and viable.Responsiveness - Some features require a set of completely new pages, with their own responsiveness rules. We always start our UI design process from the most relevant viewport. When deciding to start from mobile, the use cases revolve around quick decision-making and portability, whereas for desktop-first it’s usually a dashboard to tackle large data handling or something similar.Pattern Library - Since our projects tend to be very large and lasting and we are based on a sprint methodology, we must be extremely organized with our files. For this, we invest time in creating and maintaining pattern libraries with rulesets that govern the composition of our products. It includes structures such as component libraries, templates, text styles, system colors, alongside all types of Sketch symbols, all that in order not to lose ourselves amidst new content.<h2 id="5-usability-tests">5. Usability tests</h2>To test or not to test, that is the question. Testing the product can provide great insights and help in the decision of approving or not what has been done so far. We usually run tests at this stage, but they can also take place at other phases of the process if needed.When planning a usability test, it's mandatory to have a clear focus on what we want to validate. In our experience, trying to measure too many aspects of an interface in a single test increases the level of complexity and reduces the reliability of the results.As in the user interview phase, all of our tests are remote and can be tackled in different ways. One in which the researcher acts as a moderator and another as an observer:Moderated tests - On moderated tests, the researcher has the ability to flesh things out, explain unclear tasks, and steer the participant back on track if they get distracted.Unmoderated tests - On unmoderated tests, the researcher doesn't need to be present, multiple sessions can be conducted simultaneously, hence a much larger sample size. There are also occasions where tasks are quite specific or direct and require no direction from a moderator whatsoever.So when we discover important points to be improved or even redone, we go back a few steps, talk to the stakeholders and refine the product until it works and looks awesome.<h2 id="6-specs-for-development">6. Specs for development</h2>After an interface is approved by the client and validated with users, we tailor the produced content with specifications for the development team. The goal is to make sure that every key behaviors, states, and components are explicitly described for the developers who will build them into the live version.Inspectable specs - We always make sure to send the specs using a software that enables inspect features similar to what a browser would do. That way, developers can visualize the distance between objects inside a component, their CSS properties and such. Currently, we employ <a href="https://zeplin.io/">Zeplin</a> to bridge this gap between our Sketch UIs and devs work.Styleguides - Creating well-specified styleguides has brought us tremendous results and devs really thrive on this type of delivery.Even after the delivery we keep every communication channel open with the dev team to clarify questions about specs and fine-tuning bumps along the road.<h2 id="7-design-qa">7. Design QA</h2>To make sure the interface was pixel-perfect built, we execute the QA review checklist on the content produced by the developers after they are finished implementing it. This process happens on a weekly basis and may generate new improvements and hotfixes for the project manager to assign to the dev team. The final objective here is to keep the design debt to a minimum.<h2 id="8-follow-up">8. Follow-up</h2>Here at the company, as projects tend to be quite long-lasting, we added a step to the process, which is the follow-up phase after the delivery. We are attentive to the results that are being obtained, keep observing the metrics, and continue the journey of searching for possible improvements and updates.It is important that after every new major feature we review the product in its entirety, analyze the impact that the alterations will cause, what is already good and is working, and what can be renewed.<hr><h2 id="final-thoughts">Final Thoughts</h2>New methodologies and tools are constantly emerging in the creative world, and it's our duty as product designers to always be open to change. Also, it is important to remember that there is no point in just knowing a lot of processes and not following any of them - it is necessary to test and discover what is the design process that best fits your work environment and context.In this blogpost, we covered a brief summary of how we as designers work at Vinta. If you'd like to have further clarification about our processes or have any suggestions to make, feel free to comment below and we'll get back to you.We hope that we had contributed to your design knowledge and thanks for reading!

Join the Tech Forward newsletter

Related articles

Functional programming in Python: a little bit more

10 Django apps you're not using but should be

Don't forget the stamps: testing email content in Django