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.
Diving In
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?
Goal #1
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.
Outcomes
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.
Nice article. We have moved to a similar strategy at our advertising agency with an emphasis on sketching in the initial phases of a project before ever touching our wireframing and prototyping tools. It definitely helps to stay in a low fidelity mode until we get sign off from our internal stakeholders. In the past we have done high fidelity wireframes early on, and it often resulted in locking us into a sub-optimal design before we really had a chance to iterate on the best solution. Glad to be sketching early and often!
Nice read, Mark. I’m curious: do you think the shallow dive is a good time to do usability testing, or is it too low-fi for users to fully comprehend? I can see how it would be valuable to get user feedback early on to help shape your design, but sometimes it’s hard for users to grasp what a wireframe is, and thus give meaningful feedback.
There’s a strong focus on improving efficiency at my company as well. As a UX on a software team trying to become Agile but contractionally obligated to waterfall deliverables and deadlines, I’ve been experimenting with ways to work smarter and faster to get that ‘big picture’ design. The Shallow Dive aligns very well with what we’ve been trying to achieve in our Sprint 0. Thanks for the article.
In a business environment that emphasizes faster time to market for UX design solutions with the constraints of overwhelmed resources and restricted timelines, Buxton’s sketching philosophy is right-on if you can get your team and project stakeholders to buy into the concept and change what they know about how design is traditionally done. To do that sucessfully, it is necessary to get them to disregard years of exposure that the UX discipline has invested in building up the trappings of medium-high visual fidelity, and overly annotated wireframes that have no functional capabilities for demonstration and testing. That’s no small feat.
While traditional wireframes still have their place in certain situations, my personal preference is for an evolutionary approach that collaboratively develops rough storyboards and sketches, moves from there into medium-high functional fidelity low-medium visual fidelity prototypes (leveraging a continuously evolving pattern library) that can be easily shared with project stakeholders to validate the fit with business requirements and rapidly tested with users (both in-person and remotely) to validate the design execution. After that, the trick is to still have enough project timeline and budget left to respond to that feedback with another iteration or two or design (and more testing, as needed) until you get it right.
Thanks for your comments, all.
Julie, I usually don’t know what usability testing we might need to do until I come up with at least a germ of a solution. I usually identify that in the first iteration of a solution (the Shallow Dive). As far as wireframes, some of the documents I show to the client at that time are only wireframes by a stretch of the imagination – they are often fragments of wireframes that show two or three different possibilities for an on-screen item or area. The rest of the wirefrrame provides context for the item. Prototypes are also a natural fit for this early iteration.
In my current situation I have a natural constraint that many folks don’t have – I’m working with an application that has many (preexisting) defacto standards and (UX-driven) design patterns. We usually only test if a new or complex interaction is needed or to ‘A/B’ something – and we rarely need to test ‘usefulness’ of a change. That makes it a bit easier to determine when and when not to test.
Hope that helps.
Nice article Mark. I feel that low-fidelity wireframes give us a lot of flexibility in such cases. In addition many a times, I ask clients for some online reference that they want to emulate for UI, UX of content architecture. The only stage where I falter sometimes and cannot avoid going back-and-forth is when we need to make adjustments in UX, considering the client migration from a legacy website.
Thanks your some useful pointers.
– Vinish