Welcome to part 2 of my “Treatise on User Experience Design.” In part one, I went over how I saw user experience as a paradigm, and the disciplinary makeup and nomenclature of said paradigm.
This is the fictional tale of how I work. Not only in the sense of “how I perform my job” but also “how my mind works in this process.” Not every project requires every step, but for the sake of this writeup, I’m going to try and cover an end-to-end scenario. As I said in part one “Never time to do it right; always time to do it twice,” I am purposefully going to write this as if we life in a mythical land where process can be followed without deviation due to poor planning or impossibly constrained deadlines.
Also: This is a very long writeup. It could have been shorter, and someday perhaps I’ll edit it down. But for a blog post, it’s good SEO food!
Also also: This assumes that I’m involved in each step of the process, and in small environments where I am the only UX person, or one of few, often I do see something from conception to completion, which is more out of necessity and lack of staffing rather than choice (not to say I don’t still enjoy it).
The process of user experience and interaction design is a fractal of itself. You can zoom in on one small part, or zoom out to the whole picture. The design of the fractal is the same. It doesn’t even need to apply only to software or web development, any type of project can follow the same basic outline. In fact, it’s fascinating to see businesses and UX departments springing up in companies all over the nation, and this process of user and interaction design is nearly identical to the scientific process of Psychology research and assessment design. What was once called principles of assessment and research designs in a psych department is now just translated over into the internet and software world. I contend that the new wave of user experience is just applied Psychology and human behavior (which is why I value my Psych degree more than I would a CS or Visual Design degree). You can read that blog post here.
Are you book smart or street smart (and by street, I mean highway, and by highway I mean the information superhighway!)? There are alot of books, case studies and methods for the process of web development and the role that user experience plays in the life cycle of a project. Some of the methods I learn, some I discovered, and some are intuitive and I can’t explain where or how I acquired that knowledge.
In each company and culture, words are used for different things. Iterative, waterfall, scrum, agile, ux, ixd, ia, pm, csm… I’m going to try and just use generalized, descriptive terms and not worry too much about matching any particular flavor of corporate taxonomy.
Also – this is just how I see myself playing a role. I am not going to go over what other stakeholders or designers/developers are going to do. Only what goes on in my mind, and in my actions, is the primary focus here.
Let’s get started.
Through a series of events that lead to a creative spark, someone has an idea. Doesn’t matter who or why or what. It’s something that we’re going to assume shows promise. This someone shows up to the office, and says “I’ve got an idea for a new project.”
Alright! Genesis! We call a meeting together of the relevant strategists and planners, at this point mainly just an inner circle of idea archaeologists. Ideally there will be a representative from business strategy, technology and development, design (art and aesthetic), and user experience. We don’t know what we’ve found yet, so there’s no reason to solicit tertiary opinions until it’s actually decided if there’s any feasibility or viability. So what was this creative spark?
“A browser based system for designers to draw in a wysiwyg fashion a CSS compliant layout in a 960 grid format, that then exports the design into a fully usable, properly coded HTML and CSS template.”
Wow, okay. Sounds like a really cool idea. Into the UX process machine it goes!
Objective of Project: What is it that the creative spark wants to accomplish? This is a great time for me to stand in front of the whiteboard and just write the statement of what we’re trying to do. So what are we trying to do?
“Develop a tool that allows experienced or inexperienced people to visually create a grid based layout visually before having to see or mess with any html.” Note how this statement is different than the original idea.
So, now let’s move on to gathering data. I’m going to start with Business. How does this serve the business? Well, since we’re a (fictional) web based application development firm, this would be a useful product to add to our suite of existing products, and it would provide our own internal designers a new tool that could speed up their workflow. In the meeting, the business representative agrees that this is an idea worth pursuing.
With the input from the business segment, I now move on to generally determining who our potential users are, what functions this product will require, and the overall goal of why we are doing this. This point relates directly to the user and how it will serve them. The user experience designer is the advocate for the user at this point, and is responsible for gathering representative data and thoughts from users and integrating them into the process. UX (and it’s sub categories of interaction and information design) are there to be the catalyst between development and end user. It’s their job to give the process a target, and to hep it stay on target.
At this point in the process, I try to remind myself constantly to be flexible, malleable, and open to possibilities. Limits and moderation come in later. Suggesting means to an end is typically where this part ends and the next begins.
Identifying the User: Personas, stories, modeling
During the user discovery point of a process, there may or may not be any user data available. The idea might not have been something the user had even considered before. Since we are developing a hypothesis on how this product will be used, experience and intuition are primarily relied upon. In this point of the process, there’s been no user research gathered. Someone has to have an inkling as to the target user, which brings me right back to experience and intuition.
This is the point that I would create a basic user persona, and a story. Persona: “I am a web designer who builds html/css pages”; Story “I am interested in making my work easier and more efficient.” This is a good place to return to the whiteboard, and start freeform listing ways that both the persona and story can be fleshed out and expanded. Soliciting opinions from the users (our fictional companies web designers) would be appropriate at this point. There are two ways to phrase your questions:
“Would a visual layout tool help you work faster and easier?”
“What are some things that would help you work faster and easier?”
The first question has what is known as “face validity.” It leads the respondent to a binary choice based on the “face value” of your question. This is the Bill O’Reilly method of question. You are saying “This is what we’ve come up with, does this work for you?” While not necessarily a bad way of asking questions, it does limit the potential answers.
The second question is open ended. It doesn’t presume to know if your suggestion is what the respondent will want to answer about, and leads to a exploration of responses that you may not have considered. These answers will range from valueless, to very insightful. Once some of this data has been collected, then moving on to questions with face validity is more appropriate. It’s my job to represent the user goals, not the preconceived notions of what our business and developers have concocted and convince the user that it is what they need.
With this new information gathered, the persona and story can be modified and made more detailed and concrete. A user model begins to take form; you can start to list what the user knows, what skills they already possess, and how your new product/tool will facilitate this profile. Psychology plays a big role in this, as the tenants of human behavior, cognition, and behavior shaping have exist long before modern computers and the internet.
Armed with this persona and user model, we can move forward with an abstraction of whom we are building for.
Flowchart Abstraction and Wireframing
This is what I find the most fun. The whiteboard is the primary tool for this stage. I initially start out with a flowchart of sorts that diagrams the ideas and domains of the elements in play. It’s not a sitemap or a task flow; rather it’s a visual map of ideas, with connectors between related or connected abstractions. It’s almost like a database schema, only for intangible ideas.
This idea abstraction gives the UX team (or person) the visual representation of the concept, and a sitemap/task flow can be started. The idea-diagram surfaces the needs, and the sitemap takes them into discrete sections. The sitemap doesn’t necessarily mean it’s a website, but I like to think of it as a “site map” as in the site where a building will be built. The area of operations. The sections of the project are mapped out now in a logical fashion, and the initial draft of the project becomes tangible at this point.
Wireframing. Another one of my favorite parts. From the sitemap, I can now take the individual pages and areas and focus on them as individual objects. Interfaces, interactions, steps, and processes all begin to take shape in the wireframe. I’m not worried about specific placements or aesthetics, only establishing the needs for each section and what sort of interaction is going to be required on said section. Nothing is carved in stone, in fact nothing is permanent here at all. This is the chance to let your mind explore the granular aspects of each “View” and what options, interactions, and goals can be accomplished from each. Wireframing of this sort is best done by the UX team, as it’s the chance to put down the instruments that the user requires, without concern for technological limitations or aesthetic considerations. It’s freestyle UX creation. Typically, I do this in Adobe Illustrator. Starting out in 1995 as a graphic artist, I feel like I work faster in Illustrator than in dedicated wireframing applications. This is just a personal preference, and I probably should look into more niche software, but I always find myself going back to Illustrator for it’s function as a vector based digital whiteboard, which is all I want at that point.
Once the first draft of wireframing is done, the first draft of annotation can be done! Believe it or not, this is another one of my favorite steps. This is the chance for the UX or interaction designer to succinctly describe the purpose and initial logic behind each element. While the meaning and purpose of wireframe might be apparent to those who are familiar with the project, annotation provides a clear set of descriptors that others involved in the process can refer to. Along with annotations, the start of a technical descriptive document would be started at this point. Writing down all the initial details and documentation for the wireframes and sitemap, task flow, and idea abstraction will be a key element further in the development process.
It’s time to take a break from Psychology and move into Technology. This is an area where it’s a hit or miss scenario in the UX world. Some of the people involved (UX, IxD, IA) have a technical background and have a capable understanding of how the various programming languages work, how hardware and infrastructure work, and how the agile/scrum/iterative/etc process of software engineering and development work – and some don’t. I still hold firm to my belief that a great UX person needs to have a substantial knowledge of business and entrepreneurship, programming and software engineering, and graphic/art/copy creation. I don’t see how you can be an effective catalyst and advocate between the disciplines, on the users behalf, if you don’t have experience and a solid working knowledge of how the domains work.
Digressing back to topic of technology assessment. The decision was made to move forward exploring the feasibility of the product. This is where, as a user experience designer, I switch my mode of thinking from subjective abstractions of the user goals, and to the more objective territory of technical capabilities. The pool of human assets would be extended now to the software developers and programmers. Questions will be asked back and forth, goals and objectives shared, and UX will listen and take into account the response from the technology domain and incorporate that into the working model. Capabilities, limitations, and surmountable impediment can be loosely assessed at this point.
Designing and Prototyping
There is some debate over how comps and mockups should be presented. I try to shoot for a middle of the road approach, delivering a fairly fleshed out design, but still flexible enough to be retooled or reworked. But, there are arguments for starting out with grayscale comps with greeked text and image placeholders, so as not to distract people with colors, fonts or imagery that they might get high-centerd on and miss the bigger concept of the design. I’ve been burned on both ends of the spectrum – giving something too plain, and giving something too detailed. I think it’s a case by case judgement the UX team and prototypers have to make.
Side note: There is a old myth about a painter who grew tired of people needlessly finding things to critique about his work. Even if nothing needed fixing, people felt the need to find something to fix about the painting. So, he would always paint something noticeable and undesirable in his paintings before he showed the commissioner. In this myth, he took one of the people he was painting, usually a female, and made her arm hair a little too noticeable. The commissioners of the painting would come to critique the work, and point out “This arm is too hair, can you fix that?” To which the artist always responded with an affirmative response, thanking them for noticing such an oversight on his part.
Back to the topic. Once I’ve done comps, mockups, and/or prototypes of the views, it’s time to compare them all the way back to the initial goal, idea abstraction, wireframes. If everything went right (and in this example, it did), we should be at a stage where all the stakeholders have seen the stages, liked where it was heading, and approved further development. The prototyping stage is where things can stall out, since up until this point, serious resources, time, or money haven’t been committed to developing a working product.
The software engineers and programming teams receive the wireframes and overview documents at this point. The technical goals and limitations sh ould already have been explored earlier in the process, and it’s now time to start committing code. If the process of UX planning has been thorough, there should be good deal of wireframes, mockups, and documentation so that the engineers can get to work building in all the functionality.
The development cycle of the engineering side of things will have their own system of iterating through the process, through their internal sprints and planning standups. User Experience is just a consultant to them at this point, making sure they have the information they need and proper mapping of the desired outcome.
As releasable candidates start rolling out, they can be tested and analyzed by the UX team to provide feedback on whether or not the project is on target.
With working versions of the project becoming available, usage tests of a functional model can begin. This is where instead of rapid prototypes, we now have access to working prototypes. Interaction can be experienced. User testing can be conducted. Analysis of usage and patterns can be observed and recorded, giving the UX team time to either confirm or refute their initial hypothesis of how things will work.
Typically, this is where the pressure is on. Business strategy is eager to get things “released early and released often,” UX is busy try to ensure that things are not straying from the scope of the initial project, and engineering is trying to complete the tasks they were saddled with. Everything is starting to converge again, and the 3 aspects of Business, Design, and Development begin to form the three headed hydra that started this whole process.
There’s a demon lurking in this stage of the process. The demon of the counter-intuitive. No amount of planning or testing can account for edge cases, and they appear in the most unpredictable places. You’ve wireframed, prototyped, tested, researched, and observed your interface and interaction. Then suddenly, people start doing things that are quite the opposite of what you expected or observed in the first place. This can’t be avoided. It can’t be stopped; it can only hope to be contained.
So is this a true edge case (outside the 2 standard deviations), or did you miss something? This is a case by case thing can’t easily write an answer for. Typically, the solution comes from a mix of the UX teams intuition, experience, and deadline commitments. In a perfect world, you could go back and see what sort of interaction analysis can be performed to uncover this blind spot, but there is probably not the time, resources, or collective interest in doing that (unless it’s a real show stopper, but again, that shouldn’t have slipped past the concept, wireframing, prototyping, or development releases).
It’s the UX Designers Uncertainty Principle: You are NOT the user, and never will be. You do not have an objective, biased view. Your measurement and methods will impact the observation. Heisenberg, Schrødinger, refer to whichever physicist gets the point across. I like the idea of a UX project existing in a box and not knowing if it’s alive or dead until the REAL user opens it. I supposed if you were designing something that was intended to be used by UX designers, then maybe you could call yourself the user. Hopefully an infinite recursion loop doesn’t form and blow up the Enterprise.
This is when we commit all the SVN branches, run all the difs, and push to the staging servers. This may or may not be what happens in every deployment, sometimes all you do is upload to the webserver, but it’s a good visual.
Once the project begins getting use, the data can be collected. There’s no way to know how it will actually, objectively function in the real world with real users.
After a project is launched, it enters the cycle again. The iterative process of User Experience can start right over. Even a finished product can be reworked, have new user stories and personas held up against it, and be reworked from a new perspective.