Mark Richman is an award-winning User Experience Consultant in the Atlanta area. He has designed applications and websites for the Atlanta Symphony Orchestra, Georgia Power, Delta, AT&T and many other firms known primarily by their initials.
He is also a songwriter and a recovering mainframe systems programmer.
I recently saw a great ad for a senior UX specialist from MathWorks. Some excerpts:
Work with the development team to follow a user-centered design approach as you work collaboratively to brainstorm and design innovative solutions to complex problems.
Make recommendations to team members about which usability methods to use to answer their questions about users and design directions based on projects’ needs, goals, and constraints.
Work closely with team members to conduct user research, identify pain points, develop user profiles, and create task lists.
Collaborate on paper and functional prototypes.
Run usability tests, conduct interviews and site visits, organize surveys, and perform other usability assessments you think are appropriate.
It outlines exactly what I would expect in a UX job. We learn everything we can about a project from stakeholders and competitive products, find ways to research what users want and need, evaluate those needs with stakeholders, modify the project plan, and create solutions which are validated with users before finalizing the product.
But when I was looking for a new gig, that was the exception. Many of the job descriptions I saw asked for a wide array of UX skills, with some even asking for more than listed above. But it seemed that they really wanted a visual designer who could prototype.
Which version of the ‘suspended account’ dashboard page do you prefer?
Perhaps you don’t really care. Each one gets the job done in a clear and obvious way.
However, as the UX architect of the ‘overview’ page for a huge telecom leader, it was my job to tell the team which treatment we’d be using.
I was a freelancer with only four months tenure on this job, and in a company as large, diverse, and complex as this one, four months isn’t a very long time. There are a ton of things to learn—how their teams work, the latest visual standards, expected fidelity of wireframes, and most of all, selecting the ‘current’ interaction standards from a site with thousands of pages, many of which were culled from different companies following acquisitions or created at different points in time. Since I worked off-site, I had limited access to subject matter experts.
At a recent job, my department faced large budget cuts. When the dust had cleared, I found I had become a UX group of one. This didn’t come with a corresponding slowdown in work – in fact, following a major rewrite of our call center application, our department was already struggling to keep pace with a backload of business initiatives. Cuts slashed our BAs, our development group, and our QAs, yet everyone remaining was being asked to speed up.
I needed to find a way to work faster and smarter and decided to address inefficiencies in my design process. As I did so, a couple of key concerns stood out for me:
Get critical design decisions made as early as possible: To go from an exploratory design to a final solution, numerous decisions needed to be made by the client. To elicit those decisions, I needed to give the client wireframes or prototypes that provided a clear context. The earlier these decisions were made, the faster I could complete the detailed design.
Reduce the client’s dependence on high-fidelity wireframes: I had routinely been asked to make painstaking changes to an early set of high-fidelity wireframes, only to discard those pages as we moved towards a final solution. Frustrating? You bet. Instead, I wanted to drive the design in the manner that Bill Buxton described in Sketching User Experiences: The fidelity of a prototype or wireframe should reflect its stage of refinement. This meant introducing low-fidelity items into the process.
The concerns above dovetailed nicely, and to address them I formalized an early design stage I call The Shallow Dive.
Instead of attempting to achieve a final design solution, The Shallow Dive is an early UX analysis phase that is solely concerned with identifying design issues. The aim of this phase is to identify key elements and decisions that will influence the detailed design of the project.
To start, the BA and I do a first-wave analysis of all of the screens and workflows that might be affected by the project. Then I create a first, rough draft of wireframes. We then refine these with the development group. After discussing the wireframes with the client, the resulting decisions are carried forward into the detailed design.
The types of things that we look for might include:
What is the optimal hierarchy on each page?
What information is required to be carried from step-to-step of a multi-step flow?
What options need to be presented immediately, and what can be hidden?
Can we remove some non-critical information from the initial display?
The sole goal of The Shallow Dive is to speed the transition into a detailed design phase.
A number of things could slow this transition down. Lack of clarity in requirements may confuse translation into screen designs. Requirements that look good on paper may suffer when visualized. Without proper insight into the context of use, direction and priorities may be unclear.
To this end, within The Shallow Dive we also:
Identify and resolve key decision points affecting the detailed design.
Resolve any ambiguities encountered when the requirements are translated into screen designs.
Identify and document any usability issues that may appear.
Identify any user research needs.
This approach has worked well. It gets the client’s project manager into the spirit of iterative design right away. Since the first set of wireframes is deliberately rough and clearly emphasizes one or more design issues, the PM ‘gets it’ and understands the process of chipping away towards an ultimate goal. The PM shows those rough wireframes to their management, who become acclimated to using them to address a few key points, rather than solve all aspects of the project. If suggestions are made about an item that I don’t think is important at the present time, I make a note to ‘fix it in the mix’ and address it in the final design phase.
The Shallow Dive has some key advantages. Critical decisions are made earlier in the project, reducing the need for multiple iterations of detailed wireframes. This eliminates wasted time and shortens the design effort. Targeting the entire project allows us to present a comprehensive list of questions to the client at once, allowing for more effective use of the valuable face time with management. As well, the client gets experience in evaluating rough designs, making it easier to share ideas.
But most of all, the client accepts that design takes place in stages and doesn’t demand a comprehensive solution from the get-go. And that, my friends, is a little slice of heaven.