This all in one quality to user experience design makes the discipline fascinating, to me, at least.
For one website project I worked on, for example, we carefully mapped out the eight or nine different types of people that would use the site, identifying their goals, tasks, and expectations. The site navigation and page design was adapted to what we found through interviews and informed guesses. In user testing, however, we found more tasks and ways of thinking that did not surface in our original research. Some were subtle but all would have slipped past us if we had not tested in a lab with people.
The opposite also can happen: sometimes you act as fresh eyes and rethink a process the person winds up loving because you saved them a couple steps in their process. We're all creatures of habit. Pulling a process apart, asking questions and thinking of the answers, can surface useful ideas and solutions. A great example is the Nest home thermostat which took a passive object people set then forget and flipped the paradigm: the Nest thermostat records the temperatures you set over days and weeks then adjusts itself to save the most money.
User experience designers work with a many tools based on where they are in the product development process. For example, the start of the process often involves interviews with creators — business, development, and support staff — and the people who will use the technology. The tools are pen and paper to take notes (or typing notes into Evernote while interviewing on the phone), a wordprocessing tool like Word to write up results, and email to send drafts for review. Later stages might need drawing software like Balsamiq, Visio, or Omnigraffle to create maps to show how people interact with a software interface.
The process user experience designers follow is simple and repetitive: design, build, test. The actual journey, however, varies based on the product or software tested, the people using the software, other software or hardware like what is tested, and the organization doing the testing.
In the design phase, two key issues discussed with creators and end users have to do with information displayed in the application or device. At the least, with hardware, this involves the language people use to describe what they want to accomplish with the hardware. The words and phrases they use should show up, in some form, as button labels and in the documentation. Software also can include how information is organized into groups based on how people who will use the software describe what they need and want to accomplish. This is called information architecture or information design (see the article in this issue).
The people who will use your software or hardware are typically defined as personas. While personas have become a cliche in design and business, their essential qualities are critical to any user experience design.
A persona is a highly detailed description of one or more people who will use an application or hardware. The description can include a name, age, gender, race, economic status, back story (e.g. family, friends, personal history), likes, dislikes, basically any detail to help as you work through a design. Personas don’t replace people as you design and test. But personas do help in meetings as you debate options, for example, to base an idea or objection on a specific persona you have in mind and everyone agrees represents an ideal user of your application or hardware. From personas, you can identify tasks and how your application might fit into their needs and goals.
The impact of other hardware or software similar to what is tested also can be very interesting. Microsoft Word, for example, is so common anyone designing word processing software must consider the habits of their users who also have used Word (which likely is all their users). This can constrain your design, as well as provide ideas to fix and streamline any user experience design problems Word might have.
Capturing the words and phrases people use to describe what they want is a key part of the user experience design process. The results impact every part of the design and rollout process.
The interface design process also starts with your hands, drawing on paper ideas to solve problems identified in the initial research phase. The goal is to work quickly at this stage so drawing by hand on paper is faster than more formal methods like Visio, Balsamiq, or other wireframe software. This initial interface design work is done by a graphic designer, a marketer, or user experience designers, or some combination.
Once hand drawn interface designs work to solve problems, the next tool is Balsamiq or similar software to create loosely drawn wireframes. A tool like Balsamiq is fascinating because the output looks hand drawn. People focus more on the layout with rough hand drawn interface designs than tightly polished designs, especially at the start of the design process. The same effect applies to language: using Latin lipsum text instead of English or other modern language helps people focus on the interface design and not on the copy.
From the loosely drawn wireframes, the next step is to draw more formal wireframes and document all their parts. This step also begins to pull in the software developers because they can see the connections between the front end interface and the back end software code and database structures. For example, they might see a dropdown list on one screen appears on another screen, suggesting a single bit of code would work in both places. The developers also ask about future expansion of the system, requirements some times not included in the initial design.
From this initial requirements documentation, which might be one or more documents, the formal technical design documentation is written up. Then the system is built. User experience designers might be involved at one or two steps, to work with people to test any changes to the interface design or way the system works. They also likely sit in development meetings, at the back of the room, and listen as issues are debated in case they need to advocate for the people who will use the system being built.
Personally I find these development meetings fascinating. One piece of functionality can be designed and coded two different ways that impact how much work is needed if, in the future, requirements change (as they do). Probably the nicest professional compliment I ever got was from a systems architect who said I was the only "suit" (business person) they allowed in their development meetings. When I asked why, he said, "Because you shut up, you don't try to hijack our meetings, and when you do ask questions it's clear you've listened and understood what we've talked about." You get the idea of what user experience designers, and business people, are expected to do in these meetings: pay attention and advocate when needed.
The user experience designer also gets involved in the rollout and launch phases (sometimes called acceptance phases) of a software or hardware project. Their tools still include taking notes but might include more usability testing or focus group testing to confirm the product meets the needs of people who will use it, as well as identify areas to include in future releases.
User experience design is a skill that benefits from hands on experience with software coding, system design, interviewing, negotiations, usability testing, visual communication, interface design, and other skills involved in the design, development, rollout, and evaluation of software and hardware. While user experience designers might have twelve skills, any given day you'll use only one or two of your skills and three or four different skills tomorrow.
Ultimately, user experience designers are the advocate for the people who will use a piece of technology, paying attention to what they expect, their goals, the environment they work in, and how they define success and failure. While a product manager, for example, is concerned with user experience, they're also responsible for line of business issues like pricing, profitability, product design, and marketing. The user experience designer works more like a technical writer or software developer, a hired gun to solve specific problems as part of a team.
User Experience Professional Organizations
User Experience (UX) Blogs and Magazines
UX on Twitter
The usual suspects plus a few interesting people and groups. This list only scratches the surface, however.
User Experience Designers Tools
Here are a few tools and services. There are many others, of course, depending on your project and situation.
https://medium.com/design-ux/2e32c8306112 (Archetypes not personas)