Merge pull request #4959 from ONRR/dev

Dev-->Master

blog-site/src/pages/tool-agnostic/index.md

@@ -0,0 +1,72 @@
+---
+title: "On being tool agnostic: Picking a design toolkit based on goals, constraints, and access"
+authors:
+- Shannon McHarg
+excerpt: "Sometimes you don't get to use the tools you want to use. Don't let that stop you from creating effective designs."
+tags:
+- user experience
+- design
+- tools
+- software
+date: "2020-02-07"
+---
+Many designers get hung up on what tools to use, and most job descriptions call for skills using a specific software package.  I’ve worked in UX for about 17 years, and, with the exception of one short contract, the teams I’ve worked on have been constrained to working in one particular operating system that many designers don’t like. It’s fine to have your favorite software, but the truth is that software is just a tool to facilitate the user-centered design process, and being able to work with multiple tools makes you a more resilient designer.
+
+## Adaptability
+
+You never know when the software available to you is going to change, especially when working for government or other large organizations, where software decisions are made through contract negotiations, and the people making the decisions may not know how products are used on a day-to-day basis.  In government, software changes can also happen when products fall into or out of FedRAMP certification, or when products change their privacy and data-sharing policies that disqualify them for government use.  
+
+For example, the Department of the Interior is in the process of switching their entire productivity platform from one company to another, so our team is adjusting to using different tools for email, chat, online meetings, file sharing, word processing, spreadsheets, and presentations. This change is out of our control, so we’re having to adapt our workflows to the new world as a result.  
+
+## How to choose the right tool
+
+Even if you aren’t being forced to change software, it’s worth taking a look at your design goals before you even turn to your computer. If you focus on using a single piece of software, you may overlook a better way to meet your goals.
+
+Things to consider before creating a design artifact:
+* What are the team’s goals for using the artifact?
+* Who is the audience for the artifact?
+* How will the audience use the artifact?
+
+## Goals
+
+You need to think about the intended purpose for the design artifact before you decide on the right tool for creating it. Does the artifact need to exist in the first place?
+
+Flowcharts, journey maps, and other process diagrams exist so that stakeholders can understand a system from a high level and understand how the user and data gets from point a to point b, while highlighting various things along the way.
+
+Wireframes exist so that stakeholders can understand how each page of the product will function, so that details can be iterated on and nailed down before the system is built.
+
+High fidelity comps exist so that stakeholders can see how the system will look and feel and developers know exactly how it should look when it’s done.
+
+User research findings exist so that stakeholders can understand how people use the system and any issues they encounter when trying to use it,  and so designers know what problems they need to solve in the next iteration of the design.
+
+Take a step back from the artifact and determine your goals before deciding on the best tool for the job.
+
+## Audience
+
+Another key element of choosing the right tool is identifying the audience for the design artifact.
+
+If users need to be able to interact with a system to determine whether there are usability issues, they’re likely going to need something clickable that they can walk through. It needs to function as though it was the real product, so that users can understand enough about how it will work to act in ways they would act if it was the fully functioning product.  
+
+You can test with lower fidelity prototypes, but it depends on the goals of the study. If you want to learn whether a high-level design is going in the right direction, lower-fidelity artifacts may work. If you want to know whether lower-level interface features, like a particularly sized sort arrow, are usable, you’ll need something higher fidelity and much closer to what it will look like in the finished product.
+
+If your own product team is the audience, reviewing and giving feedback on a design, the key is to have something that you can use to get ideas out of everyone’s heads and into a visible form to help get everyone on the same page.  It’s also nice to have commenting functionality for this type of audience.
+
+Some audiences also require higher fidelity artifacts than others. Often, people who are disengaged from the digital world have a hard time visualizing how a wireframe will turn into a finished website, while at the same time, they can think that higher fidelity comps are almost done, and they can snap their fingers and have a finished website. Other audiences are less likely to provide feedback on something too polished because it feels done, while something more sketchy or rough invites more feedback.
+
+It’s a difficult balancing act and may require some experimenting to find the right level of fidelity for each audience you have. It may also mean having more than one version of a design for different audiences.  Some tools make it easier to have multiple versions by providing toggles that let you switch between lower and higher fidelity artifacts.
+
+## End use
+
+You also need to think about the end use of the artifact. Will people just be viewing the artifact? Will they need to comment on it? Edit it?
+
+For example, in a previous job, we laid out wireframes in a word processor because that was the only tool everyone had access to, and it was important for people without design software to be able to edit and copy and paste text from the wireframes.   
+
+Because most of my colleagues at the Office of Natural Resources Revenue don’t have design software, we used this approach to do wireframes for our team’s intranet page. It was an effective way for them to get feedback on the visual layout before investing the time to build the pages.
+
+Wireframe created using a word processor:
+
+![Wireframe created in a word processor, with breadcrumb navigation at top, title of Information and Data Management, and sections for mission, data display, data governance, and data retrieval in the main column, with a right column containing contact information and related links](./Wireframe.png)
+
+## Conclusion
+
+In addition to ensuring you can do your job under any conditions, being flexible with what software you use for your design artifacts can go a long way in spreading design capabilities within an organization. If you get hung up on using specific tools, you limit design to only the select few who have approval for the tools. Using the tools your organization has available can open the door to others picking up the skills, because they see you using tools they have, and they might just try using the tools you’re using to start design conversations themselves.