Useful, Saleable, Buildable: The Role Of UX In Defining Requirements
This is a guest post by our friend Mike Hughes.
A mentor of mine is fond of giving the advice “Do what you love to do in the service of those who love what you do.” Whenever I hear UX professionals complain that they are continually having to promote the value of what they do, I wonder if they are serving the right people. If people in your organization are not seeing the value you add, maybe you haven’t positioned yourself where you can add the most value.
In this article I’ll explain how my role has evolved from that of a usability expert to that of a user experience (UX) architect. In making that transition, I have increased my impact on product strategy and I have established a higher perceived value in the organizations I work for. Essentially, I will discuss how my emphasis and contribution has shifted from just making the product usable, to defining a product that is useful, saleable, and buildable.
The evolution of a UX architect
Like many other UX professionals, I got into UX through usability testing. And like many people in usability testing “in the day,” my involvement with a product usually came late, literally days before a scheduled launch or even after a product or web site was already in the market. My major challenges back then involved problems with UI design that could not get adequately fixed because of time constraints or because the problem had been baked too deeply into the technical architecture of the product. I went through so much pig lipstick in those days that I was on Miss Piggy’s speed dialer.
Then I landed a job with a different company and made the formal transition into UX. This let me move further upstream in the development process. My early UX experience involved working in the design phase, producing detailed Visio wireframes based on a product manager’s Product Requirements Document and then delivering those wireframes to be coded into a working user interface by the developers.
As ideal as that sounds, I started encountering new difficulties. In particular, there was one product manager, “Dave,” that the design and development folks did not want to work with. For one thing, he would look over the shoulders of the QA testers and start complaining that the product wasn’t what he had envisioned when he wrote the requirements. Eventually, he started sitting with developers during coding so that he could shape the product to his expectations.
All of this was going on in a company with an expectation that products were to be built to requirements and the wireframe was the functional specification for how the UI should look and operate. The situation was made particularly painful because Dave was often right and his meddling resulted in noticeable improvements. Doh!
While everyone else was wondering how to get rid of Dave, I was wondering how we were managing to not please him. This was his product, these were his requirements, he was right there in easy reach, and he was certainly not shy with his opinions. How, then, were we missing a target that big?
With the help of another UX designer who had recently introduced me to Axure, a quick prototyping tool, we started to change the design culture.
Instead of acting like building architects producing detailed blueprints, we started acting more like police sketch artists ala “His nose was big,” “Like this?” “No, longer, and not as wide.”
In our new model, the design phase became highly interactive and iterative. We would quickly put up prototypes and ask, “What if it looked like this and acted this way?” Wow, did that get some good conversations going! And because our wireframe tool generated what at least acted like working prototypes, we could do usability testing to get real user feedback and test competing design ideas. By the time we started coding the product, Dave knew exactly what he was going to get and either loved it or had accepted the compromises he knew we would have to impose.
UX Documents as requirements — not just design artifacts
In my current team, we have taken this model of a highly interactive and iterative design phase to an even higher level—letting the UX design artifacts replace the requirements documents altogether. Part of our push has been the need to accommodate our development methodology of SCRUM. SCRUM is an Agile development process which emphasizes minimum design documents and which values “learn as you go” as opposed to “If we think long and hard enough ahead of time, we will anticipate everything and will build the optimal solution.”
Our primary UX design documents that we use to define requirements are Scenarios and Wireframes. Essentially, our scenarios are two-act plays. We label Act I “Problem” and Act II “Solution.” The Problem section can be as short as one sentence or as long as several paragraphs, depending on the complexity of the requirements scope. Problem sections can reflect the shortcomings of an existing process, functionality that is missing from a current offering, or can capture complaints we have received about our current product’s performance.
What is important is that they establish the context in which the required function will add value for the customer. It is often an early warning if we have difficulty positioning a requested feature within the context of a customer problem it would solve or alleviate.
The Solution section is a narrative that describes an alternative experience to the one described in the Problem section—one brought to a happy ending by the product feature to be built. It is not a detailed specification, but rather a loose contract between the product manager and the developers about how the solution will look and act—in the context of an authentic user situation.
We often supplement the narrative text with low-fidelity wireframes. We use Balsamiq Mockups because it renders a hand-drawn look which reminds everyone that this is essentially a conceptual piece. For example, a rough drawing of a calendar date selector tells the stakeholders there will be an easy way for the user to enter a date; it tells the developer to insert the appropriate date selector widget from our approved widget library.
These low-fidelity mockups have the advantage of being quicker to produce than prototypes, but they are not as useful for usability testing. And that illustrates another shift from my role as usability tester to UX designer. The focus at the front end of the project is less about “Would this be usable?” and more about “Would this be useful?”
For example, in the early stages of setting requirements for a new report, I am more interested in capturing what information a user would need to see in that report and how the user would want to manipulate the data, e.g, learning which attributes users would want to filter by. It is later in the development phase that I shift my emphasis more to how intuitive and usable are the widgets and the UI in letting the user run, schedule, and manipulate the report.
Starting the good fights
The combination of the narrative of the scenario and the rendering of the wireframe gives us an artifact that we can put in front of users and stakeholders and ask “Would this have value, is this what you want?” We can also put it in front of developers and ask “Can we build this and for how much?”
And that’s when the “good fights” begin. My experience has been that stakeholders and developers can think they are in agreement over traditional requirements and specs when they really aren’t. The combination of a scenario and one or two supporting wireframes, however, surfaces any disagreements quickly and in concrete terms that can be resolved. These new artifacts become a Lingua Franca, i.e.,“…a language systematically used to make communication possible between people not sharing a mother tongue, in particular when it is a third language, distinct from both mother tongues.” (1)
The following is a screenshot from our wiki page where we post our scenarios, and it shows an illustrative example of a scenario and wireframe. Stakeholders have access to these pages and can “follow” them to be notified any time we update them as well as comment directly on them.
My journey in user experience has led me from being involved at the end of the development cycle and asking “Is this usable?” to being at the very front end of the process helping to define requirements around “Is this useful to a customer?” “Could we sell it if we had it?” and “Can we affordably build it?” One of the biggest differences this has made is on the impact that UX has on the business: We are major players in setting strategy that influences product profitability.
The engineering manager who hired me into my current UX position defined engineering productivity as “revenue divided by the number of engineers.” And he continually warned us against getting overly involved in development projects that could not show a positive impact on revenue.
So by all means, keep your usability “chops,” but use them in a supporting role as you pursue the real prize, namely, defining products customers will want to use, the business can sell, and engineering can build economically.
(1) Viacheslav A.C., The problem of the Caucasian Sprachbund in Pieter Muysken, ed., From Linguistic Areas to Areal Linguistics, 2008, p. 31. ISBN 90-272-3100-1