“It’s about catching customers in the act, and providing highly relevant and highly contextual information.”
— Paul Maritz, CEO at Pivotal
— Paul Maritz, CEO at Pivotal
I spend time learning about the client that hires me, the primary and secondary existing & prospective users of the product I’m being tasked to work on, and the goals that the client has for the product and its users. I like to attempt to understand the goals and context-of-use before a “deep dive” session to anticipate any UX or information architecture flaws before the bias that comes with client-driven knowledge sharing.
My goal, during this phase, is to understand what is obvious or natural about the content strategy, the tone of the writing, and the universe of accomplishable tasks. I spend time understanding the deeper expertise of the client and about the industry they are in.
I, then, turn my attention to the future of the product by getting from the the client or identifying logical prospective users. I want to learn how they approach the identified tasks, get into the mindset of the user when they’d turn to use the product, and, finally, I like to see what other products do to help users accomplish the same tasks.
I work with the client and any research I can get ahold of on the users to see what the product hopes to do and every step needed for a user to do so. Some of the steps can include offline activities such as administrative approvals, file preparation, processing by bank systems, delivery wait times, etc. I partner with technology to create cross-team transparency between what occurs on the front-end and what results of the back-end of technology; I like to identify, what I call, "the forest of possiblities."
I identify the tasks most important to the client’s business and the ones most important to primary and secondary users. These do not always align and I strongly believe that difference between good UX and great UX is the factor of delighting users by making what they care about most easy to do, even if not the most important to "the bottom line."
I know it may not be a popular thing to admit, but I don’t like to sketch. I rarely doodle ideas or do extensive low-fidelity digital wire framing. Instead, I create mid-fidelity whiteboard drawings that inevitably get shown to a boardroom full of people and fellow designers, a term I loosely use to describe the problem solvers I partner within technology, visual design fellows, marketing, branding, and legal (yes, even legal wonks).
I love to take over an entire white board (even if it’s the entire wall and I’m standing on chairs). I then move to rapid prototyping and love using Sketch, InVision, and the Adobe Creative Cloud (I've grown up using it and find it great for simple mockups).
I start problem solving rather quickly. I like to get sign-off for page-level designs to ensure they meet business requirements and are feasible based on allocated resources on the fronts of technology, training, customer service, and preferred timelines. As Marcin Treder of Smashing magazine once said, "Unfortunately, testing lo-fi prototypes is not popular. We prefer to take the risk of choosing one option with a stakeholder and begin the refinement process."" This is my reality and this is why I like designing the little details, life a leaf of a tree in a forest. ;)
I often find myself working with a client that uses agile project management, a method I fully supported as an early full-stack web developer. I can work as a UX designer within Agile, but it definitely becomes more formal and bureaucratic than I believe to be necessary. That being said, I am well-known to be the "king of excel" and love to organize via meticulous file naming, version control, and mastery of transparent progress reports via tools such as VersionOne, Podio, Trello, and Atlasssian’s software suite (think Hipchat, JIRA, and Confluence).
I constantly get buy-in from key stakeholders and recurring user testing to ensure designs are going in the right direction and that technology is bringing to life the needs of the users and the client. I’ve spent a lot of time working with government organizations, non-profits, and entities heavily bogged down by bureaucracy, so I’m particular experienced in the politics of getting people onboard with change and the implications it has for product growth and internal business processes.
Having worked with lovely organizations such as UXPA and alongside amazingly talented professionals with disabilities, I know how important it is to do the right thing. We must make sure color contrast, alternative tagging, sightless navigation, word choice, information architecture, and overall design choices keep the needs of web accessibility in mind, at all times.
Compliance with Section 508 (of the Rehabilitation Act of 1973) is not always enough and I’m always willing to spend the extra time to get things right. Improvements to interaction design, typographical workarounds, and the steps that can be taken to make the changes made for accessibility often benefit the overall user experience.
Matching requirements to solutioning throughout the entire design process makes acceptance testing a breeze. I love to confirm that the ideation and iterative approaches to problem solving have worked. Data speaks plenty but happy users speak with more important numbers: the smiles, thank you emails/tweets, and ultimately happily spent dollars.
As is true of modern politics, improvements come slowly with hard work and attentive listening to needs. I'm a strong supporter of staggering releases, capturing data to influence necessary rework and future releases.
Benchmark, compare, improve, and learn. Happy customers usually make for happy clients, at least in my experience. You have to get things in users' hands to really begin to measure "good UX."
ITERATE (& POSSIBLE HAND OFF)
This time with less sticky notes.
Note: "Make this pretty" are the last things you should ever say to a UX designer.