Beyond Wireframing: The Real-Life UX Design Process

Advertisement

We all know basic tenets of user-centered design. We recognize different research methods, the prototyping stage, as well as the process of documenting techniques in our rich methodological environment. The question you probably often ask yourself, though, is how it all works in practice?

What do real-life UX design processes actually look like? Do we have time for every step in the process that we claim to be ideal? In this article, I’ll share a couple of insights about the real-life UX design process and speak from my own experience and research.

User-Centred Design: Truth Vs. Fiction

A few years ago, I joined one of the biggest e-commerce companies in Eastern Europe. When I entered my new office, I immediately spotted a huge user-centered design (UCD) poster on the wall. The whole process was described in detail that left hardly any doubts about the step-by-step approach to design. Exciting interior design for an aspiring UX designer, right? I stared at the poster with great hope and imagined how exciting following the ideal UCD process would actually be. Guess what? They didn’t apply a single step from the poster to the actual process. They never did any research, nor any serious analysis of user behavior. Yikes, they didn’t even prototype! This fancy poster simply hung shamefully on the wall.

For the next three years, we worked hard to put user experience design at the heart of a developer-driven culture. We forgot about the poster and structured our own process, which fitted well with the company’s capabilities and allowed us to constantly optimize our main service. Why didn’t we use the crystal-clear theoretical approach? Because we couldn’t afford to go step by step through a classic UCD process with a lot of different activities. It would have taken too much time, and therefore it was economically invalid — the budgets for our projects were way too tight.

To deliver a user interface on time, we were forced to get really lean. We used a classic UCD process as inspiration and created a process that was simple but actionable for the company. We defined the problem, defined the scope of the project, iterated through paper prototyping and wireframing, pushed code to production as fast as we could, and always used multivariate split-testing and detailed Google Analytics event tracking.

Post-launch was the time to measure and plan optimization, which we executed immediately. Unfortunately, only huge projects had budgets for qualitative testing. Huge projects were also full of preliminary diagrams (site maps, flow charts, conceptual diagraming) — a enormously recommended activity to find order in a complex mess of information.

All in all, our process was simple but efficient. Of course, in general terms, it was a UCD process, but compared to any popular approach1 and a famous UPA poster2, we used about 20% of the recommended tools and studies. We assumed that users don’t benefit from poster unicorn processes. Users benefit from the hard work of a product team; therefore, a simplified process is better than a robust unactionable theory.

UPA UCD Poster3
Designing the user experience. (Large version4)

Suddenly, I started to wonder how others managed to apply UCD. There’s a lot of talk about wireframes, but what does our work look like beyond wireframes? Was I the only one with a simplified approach? What can we do to create successful designs? What does the process beyond “the poster” look like? Is there a pattern that works well for the majority of designers?

The Reason For Research

Luckily enough, I was about to find some answers to my questions about the design process. I was forced to perform a worldwide reality check on my opinion about the classic UCD approach and design processes. Sharing this reality check is the raison d’être of this article.

  • If you’re fresh in the UX design world, learning how more experienced designers work might be useful.
  • If you’re a seasoned designer, treat this article as an incentive to reconsider your approach to design. We’re all rushing our designs every day. This is the time to take a breath, see what others are doing and think about what works and what doesn’t work in our real-life approach — beyond a UCD poster.

You may wonder what force persuaded me to revise my approach to the design process. The answer is simple: my own startup. Together with my friends, we created paper prototyping notepads to make our process more efficient, and then we created our own collaborative wireframing application. We suddenly became quite popular, took VC investment and decided to face the challenge: to create a user experience design toolset to support teamwork in the design process.

We felt that we were trying to fight Godzilla (or Tywin Lannister, if you prefer Game of Thrones to old Japanese movies). If my UX teams couldn’t apply a classic UCD approach, how could I be sure that using any theoretical framework would enable me to design a toolset that fits anyone’s real-life process? I couldn’t. Is there any pattern in design processes that we actually apply in our companies? I had no idea.

We felt that we needed to find out the truth about real-life design processes and we needed it now. It appeared to us that our research might be of vast importance to the community and even beyond. A simple equation: a great tool for the design process equals less work for designers on the tools side, equals more time for creative work, equals better designs for all of us.

The stakes were great, and there was just one right thing to do: get out of the building, get our hands dirty with research, find out and learn about the real-life design process (if it exists), and literally hunt out pain points in it to make the work of our team much easier and more pleasurable. We packed our stuff and crossed the great pond, so to speak, to do some serious research in San Francisco and Silicon Valley. Read on if you want to know what we found out about the design process!

The Customer Development Process And Tons of Individual In-Depth Interviews

The life of a modern startup is full of UX design work, even if the founders don’t realize it. Drake Martinet (Wall Street Journal, Stanford University) considers the whole lean startup movement to be a mere application of design principles to the business environment. I couldn’t agree more.

When starting a new project, you actually need to talk to people from your target group. Here comes what are well known as IDIs (individual in-depth interviews): moderated, individual interviews in which you try to learn as much as you can about the problems of your interlocutor in a particular area of their life.

Our target group was user experience designers, so we scheduled above 50 interviews (personally and via Skype). Each focused on the same theme: the real-life UX design process. We asked designers to tell us stories of their usual process based on one of their projects. During the interviews, we asked a ton of in-depth questions to learn as much as we could about the process.

We hardly asked about problems in the design process, though — we tried to spot them in the stories on our own and then confirm our judgment by asking questions (for example, “I understand that X was troublesome in this particular project?”). We tried as hard as possible not to push any views onto our interlocutors. Letting them speak was important.

We interviewed UX heroes Mike Kuniavsky, Indi Young, Luke Wroblewski, Peter Merholz, Brandon Schauer, Jeffrey Kalmikoff and John Zeratsky and some lesser-known but excellent UX designers. Among our interlocutors were in-house UX designers, designers from consultancies and freelancers. Surprisingly enough, the problems that usually trouble UX designers were similar in all three groups.

It was an intense learning experience, and I highly recommend considering such preliminary research in every project. It will give you a ton of ready-to-use knowledge — a kind of canvas to work from.

The Process That Emerged From Designers’ Stories

First of all, we didn’t find any unicorns, but we did find racehorses in excellent condition. While all of the processes that emerged from the stories were somehow simplified UCD processes, they were tailored to the specialities of the designers. Flexibility is what helps us survive in the diverse jungle of projects. Processes morph to fit projects.

The approach to an e-commerce website differs from the way we design mobile apps in the healthcare industry (guess where context analysis matters most?), and government clients differ from corporate stakeholders and startup entrepreneurs, and so on. With few exceptions, though, the process looks surprisingly similar. There is a visible pattern that we all use to design interfaces in different environments:

1. Collecting Information About the Problem

Every UX designer needs to be a kind of detective in the early stage of a project. We need to find out as much as we can about the three Ps (people, problem, project). Activities in this stage, in contrast with the classic UCD approach, are vastly simplified:

  • Meeting with the client (no matter whether externally or internally) and identifying the product’s requirements (often in the form of a standardized product requirement document);
  • Benchmarking and trend analysis (oh yes, most of the designers we interviewed do that).

We seldom perform user interviews, but writing user stories is one of the commonly accepted attachments to the product requirement document. Our user stories are sometimes created based on personas, which are hardly ever backed up with data. Field studies and task analysis are hardly used by any of the designers we interviewed.

2. Getting Ready to Design

This is clearly the ideation part of the process. It’s completely conquered by analog tools. I haven’t met a single designer who doesn’t use quick messy sketching or some other paper prototyping form at the early stage of a design process!

Designers try to act on the material gathered in the first step of the process and find a design worth refining. This stage is not about documenting; it’s about artistic fury and creative explosion. Many of us use Adaptive Path’s multipage templates5 to quickly create very generic sketches.

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. Not very UCD-like, but that is the reality.

3. Design

In contrast to the anti-documentation agile approach, most of the interviewed designers create wireframes and prototypes to document the experience and then hand them to the developers.

Refined sketches from the previous stage are still rather lo-fi and are usually not tested. Hi-fi design is left for visual designers. In Aristotelian terms, we create the form, while developers and visual designers fight to create the matter. Heuristic evaluation is definitely out of fashion, while expert review backed up with a cognitive walkthrough is quite popular.

4. Approval

This is surprisingly an important part of the design process. Research documents and deliverables usually also serve as persuading factors in the “buy-in” process. This does not differ between in-house UX designers, freelancers and folks from consultancies.

Buy-in is the unfortunate peak of our process. None of us want to see our work go directly to the trash, and I’ve seen some great projects rejected just because the story behind the design process wasn’t particularly persuasive.

And guess what? A lot of the interviewed designers actually create a special presentation to tell stakeholders the design story. The presentations show stages of the process, deliverables and interactions, and they aim to give stakeholders lazy access to all of the information.

The four points mentioned above form a pattern visible in the majority of design processes that we went through with our interlocutors. You might have noticed that not a lot of iterative research is done in these processes. Sadly, the classic usability study is not a permanent part of the process. Why? The answer is simple: budgets are tight. Problems that appeared in the company that I used to work for appeared to be common. Tight budgets are forcing UX designers to tailor their processes and skip costly research.

I believe the best answer to this problem is guerrilla research methods. Startups do adapt guerrilla research as a part of the customer development process, but more “mature” companies, in my opinion, are strangely afraid of spontaneous and methodologically questionable yet efficient and cheap research methods. One of the challenges of the UX design community in the coming years will be the popularization of guerrilla research methods and bringing them into our real-life design processes.

Houston, We Have Several Recurring Problems

During our research, we tried to spot recurring problems in the design processes of our interlocutors — a so-called pattern of pain. Surprisingly enough, similar problems appeared in almost all individual interviews. Apparently, a lot of us live arm in arm with three tough unresolved problems that tend to slow us down:

  1. Spreading an understanding of the design process
    How to engage the whole team in the process and show them that UX designers are not people who lack talent in visual design yet still insist on drawing something? How to teach that there’s user experience beyond wireframes?
  2. Communication within the team
    How to communicate with a team throughout the process and actually use different perspectives of teammates to evaluate design deliverables?
  3. Demonstrating the process to get buy-in
    How to present the design process to stakeholders and developers to actually get buy-in, both formally and psychologically?

6

One of the UX designers we interviewed said the following:

Do you know what the most painful thing is in my job? Bureaucracy. Having to go to meetings. I would rather design than fight over the picky details. We should make at least part of the workflow online instead of in person. Have the approval process online, instead of in a meeting.

Another said this:

It’s really hard to show the process to clients and spread some understanding of the importance of design.

We have probably all tried to solve these problems countless times, but we still lack efficient and fast methods. This results in less time for creative work and research.

My hypothesis is this. We as UX designers need to resolve the three painful problems identified above to have more time for creative work and research. We need to demonstrate our work beyond wireframes, spread understanding of UX design and, in fact, sell ourselves both internally (within the product team) and externally (outside the product team, in front of clients and stakeholders). This is the recipe to increase our effectiveness.

Our real-life UX processes need adjustment, and since we share the pattern of the process and the pain points, we can solve them together. This is most likely the most positive outcome of this research.

Outcome Of The Research

The research shows that UX designers are constantly modifying the classic and complex UCD approach. Less emphasis on iterative usability studies and a narrower range of design activities (compared to classic UCD) are the main traits of the current real-life design process that have emerged from our research.

A process tailored to the capabilities of our companies and our clients proved to be generally effective, but it still causes some recurring troubles that should be eliminated.

This is, generally speaking, the state of our field. Don’t get me wrong: I don’t mean to criticize classic UCD — it still serves as an inspiration for our work. After all, I’m happy that I worked in that office with “shame” hanging above my head (yes, I mean the UCD poster), which constantly reminds me of the need for adjustment in the process. I’ve learned that what matters, though, is an actionable process — possible to use, adapted to the company’s culture and financially effective.

After talking with dozens of UX designers, I’ve started to wonder, however, whether we should actually create a poster that shows this version of the process. It could help a lot of aspiring UX designers take their first steps in the field and could be effective as an educational tool for our internal and external clients.

After all, our work is not nearly as expensive and time-consuming as the old poster says.

P.S. A study of the process and the problems spotted in it inspired us to create “The UX Design System7” — it’s a work in progress, and I’d love to hear your feedback.

Further Resources

Front page image: Image credits go to the Wireframes website12.

(al)

Footnotes

  1. 1 http://www.usabilityprofessionals.org/usability_resources/about_usability/what_is_ucd.html
  2. 2 http://www.usabilityprofessionals.org/upa_store/books_and_posters/index.html#poster
  3. 3 http://www.mprove.de/script/00/upa/_media/upaposter_85x11.pdf
  4. 4 http://www.mprove.de/script/00/upa/_media/upaposter_85x11.pdf
  5. 5 http://www.adaptivepath.com/ideas/sketchboards-discover-better-faster-ux-solutions
  6. 6 http://www.flickr.com/photos/piruwayu/5662362732/
  7. 7 http://www.youtube.com/watch?v=A6aGep7eFDs
  8. 8 http://www.smashingmagazine.com/2009/09/01/35-excellent-wireframing-resources/
  9. 9 http://www.smashingmagazine.com/2010/08/27/free-wireframing-kits-ui-design-kits-pdfs-and-resources/
  10. 10 http://www.smashingmagazine.com/2010/06/16/design-better-faster-with-rapid-prototyping/
  11. 11 http://www.smashingmagazine.com/2010/03/29/free-printable-sketching-wireframing-and-note-taking-pdf-templates/
  12. 12 http://wireframes.linowski.ca/

↑ Back to topShare on Twitter

Marcin Treder is a design enthusiast that literally lives for creating the best user experience possible. After years working as a UX Designer and UX Manager he focused on his own start-up UXPin that provides tools for UX Designers all over the world. UXPin tools are used by designers in companies like Google, Apple, Microsoft, IBM, Salesforce. UXPin was recently voted the best start-up in Central and Eastern Europe. Marcin enjoys writing (e.g. for UXMag, DesignModo, SpeckyBoy...), blogging (Blog UXPin, UXAid, Startup Pirate) and tweeting (@uxpin, @marcintreder).

Advertising
  1. 1

    Wendell Fernandes

    August 29, 2012 5:36 am

    User experience is heavily related to the emotions it conveys to users/visitors. One of the things I have found out about the process of UX, is the important fact that ultimately UX should begin from within the organization. It’s imperative teams work well together and process it all cohesively. It’s clear that nowadays, UX has become what it should not, that is the train carts, instead of the locomotive force which pulls, drives and guides. UX and its process has to begin from within, relationships, interaction between teams, and this great experience, will drive the experience from our visitors and users.

    23
    • 2

      Couldn’t agree more! Thanks for wise words Wendell!

      0
    • 3

      Anders Schmidt Hansen

      August 30, 2012 11:07 pm

      I second this completely. And to elaborate on this comment in combination with Marcin’s excellent article, you would be surprised how this “unicorn process” is still heavily preferred at my university. Which stands in stark contrast to the fact that actual UX companies make their living in offices just next door to our classrooms. If I didn’t have articles like Marcin’s here to keep my mind up to date on this subject (even though I admit to find myself doing more a mix between visual design and front-end development spiced up with UX work), I would be years behind.

      So thanks for a great article and for doing some real-life research on this matter.

      3
  2. 4

    I like the way you presented the UX Design Process! Its Great!

    “User Experience” is like culture, it changes. The way we dress, communicate and the way we analyse the subject, it changes. Better UX should come with deep study of where we are and what we need right now! Common sense is the key to design a better user experience, no posters needed. :-)

    3
  3. 6

    I definitely agree with everything. Thanks for this article.
    I think that UX is very near to Product management but often it is seen as mere interface design (and also confused with graphic design and front end development). For this reason, people in the team and external stakeholders expect something different from us. Sometimes they feel confused in front of a set of low resolution wireframes or in front of storytelling scenarios and storyboards (few days ago somebody asked me what I was doing with the coloured pencils!). They also don’t expect the design of new features (sometimes grabbed from lateral contexts of use).
    In my experience, showing a design is similar to sell the idea to somebody (it may be a client, your project manager or the developers). The success of this ‘selling’ depends on the story behind and on how this story is told.
    Sharing too many technical information about the design (such as IA, interaction flow and so on) may be confusing for them. At least at the start. They want to see what happens and/or how it affects the market/users/their interests.
    Sometimes I feel that showing the idea is harder than the design itself.

    About the classic UCD, I guess it is good to continue to keep the old poster. It is a inspiration and also a reference. The higher you aim, the higher you’ll hit. So hopefully, this is the method we aspire to follow. In reality… well, we know! Sometimes we use a technique and sometimes we use another one. Depends on the context, on the possibilities and on the environment. The classic UCD is a good reference of all the possible available techniques we can use in different contexts. It is our treasure box. When we need it, we open the box and we get the most appropriate tool.
    Spreading the awareness of this flexibility is a good idea though ( and a good help for the young designers’ mental health!)

    16
    • 7

      “Sometimes I feel that showing the idea is harder than the design itself.”

      Agree! Sometimes it is! The important thing to remember is that designer’s work doesn’t end up on preparing documents and sketches. It’s all about communication with the team and…making the design happen.

      Thanks for the kind words!

      4
  4. 8

    This is very surprising, “We seldom perform user interviews, but writing user stories is one of the commonly accepted attachments to the product requirement document. Our user stories are sometimes created based on personas, which are hardly ever backed up with data. Field studies and task analysis are hardly used by any of the designers we interviewed.”

    User centred design but you are reporting not performing user interviews and personas which are hardly ever backed up with data? Field studies hardly used. How can this be user centred design?

    9
    • 9

      This is the finding and I agree it’s quite far from the classic approach towards UCD.

      Either so designers that I interviewed are of absolutely top class and they create well performing products.

      I’d say that designer’s work should be judged by the final result (a product and its performance) rather than methodological approach.

      3
      • 10

        You talk about research ‘findings’. Can you tell us more about your research method? Your sampling for example? You state that, “many of us use Adaptive Path’s multipage templates” and you list quite a handful of designers who have come from Adaptive Path amongst those you interviewed, so I can see why they might use Adaptive Path templates.

        It is very strange in this day and age to talk about a ‘classic approach to UCD’ and contrasting it with a more modern approach which involves no UC at all in the D !

        12
  5. 11

    stakeholder report on creating stakeholder reports.
    like it.

    0
  6. 12

    Is that me or what. For a Webzine on UI-UX, this site is loaded of Ads and visuals distractions, yet we have to search to find the Share functions…

    6
    • 13

      No kidding. At the top of the article my eyes were assaulted with six columns.

      10% 12% 24% 24% 15% 15%
      nav nav content add add add

      and the content column wan only 28 characters wide. <- why do I come here for design advice ?

      Also, who voted down your comment? My bet, someone that works at smashing.

      0
      • 14

        The writer of this article has nothing to do with the UI elements you criticize. Send your feedback via appropriate channels, and write about the article in this comment thread. Thanks for your understanding!

        9
    • 15

      You are not alone. I also spent time finding the share function…

      2
    • 16

      You should try “Clearly”, a great chrome plugin by the creators of evernote. It takes away all distractions and lets you read the actual content that matters!

      5
    • 17

      For me it’s okay. The obvious padding between article and navs/ads gives my eyes focus on the article.

      0
  7. 18

    Excellent findings and great knowledge to spread around. Thanks for sharing!

    From a pain point problem, communicating the need for UX becomes easier when one has a holistic view of all areas that will be implementing the UX. So putting the UX in terms that visual designers and developers can understand vs. just handing them the product, is key.

    4
  8. 19

    “We seldom perform user interviews, but writing user stories is one of the commonly accepted attachments to the product requirement document. Our user stories are sometimes created based on personas, which are hardly ever backed up with data. Field studies and task analysis are hardly used by any of the designers we interviewed.”

    Why is that?

    3
  9. 20

    Investing in UX has such a high ROI that more and more companies should value every word from a UX designer. It’s a field that seems to require a ton of patience and willingness to meet people where they are. It’s like being a medical doctor to ‘injured’ websites.

    4
  10. 21

    Thanks for outlining the results of your research! I’ve always wondered if I was skipping research and analysis steps to meet tight deadlines and budgets because of some shortcoming in my communication skills, or if this sort of practice was common. It’s good to know that I’m in good company!

    It’s definitely tough to convince our project owners to invest a little extra time in the UX process, but we’ve learned to make do as well. It’s all about leaner deliverables early on in the process (Style tiles/wireframes/charts instead of functional prototypes/hi-fi mockups).

    1
  11. 22

    Just as from manufacturing age to marketing age(age of plenty)…
    UX is also just a demand of time, no matter what difference in opinion ,it can’t substitute the power of visual design or the right brained developer.
    I think the UX can be implemented easily by visual designer as it would require only some amount of common sense , just a mix of psychology and marketing that’s all..
    Its reality that its just need seeking and goal matching procedure and nothing beyond.
    Its just a Bubble about to burst.

    -22
    • 23

      I don’t think so. For me, UX is more closer to software engineering.

      If you’re working with websites only, then the visual design and ux could be mixed, that’s fine, especially if the site is small.

      But when it comes to huge internal applications, grids, alignments, proportions are secondary, and the tasks within the application and the paths to execute those tasks becomes primary.

      I think UX is different exactly in what cannot be displayed on one page.

      It’s true, a lot of things are just shiny. I don’t like shiny designs. And I especially don’t like shiny interactions, they’re usually hard to learn (or in UX-speak: their affordance is low).

      That said, most design activities have something in common: mechanics or architecture doesn’t really differ from software engineering just in its tools, software engineering doesn’t differ from UX but it has a bit of different viewpoint perhaps, and UX doesn’t differ from architecture.

      I think it’s more a question of emphasis: UX brings its emphasis more on the user, while graphics design brings emphasis more on the visuals. It’s a bit more about the personality of the creator, than the task at hand, albeit not all tasks match the creator well.

      9
  12. 24

    A welcome bit of investigation and commentary. Two things:
    1. A theory is an explanation of a phenomenon. A hypothesis is a testable element of the theory. The results of the tests are evidence that might validate or invalidate (not prove or disprove) the theory.

    THEORY: “We have observed X. We think X is happening because Y.” [Y is the theory.]

    HYPOTHESIS: “If THEORY Y is a valid explanation of X, we would expect to see Z condition (behavior, attitudes, etc.). [Z is the hypothesis.] Z condition has different parts and motivations – A, B, & C. We shall test A, B & C. If the overall Hypothesis Z is valid, then Theory Y might be a true explanation of X.”

    These tests can be in the form of expert reviews, putting prototypes in the field, in the lab, or directly into the market. Just be ready to measure the before and after results and be ready to keep, modify, or trash the hypothesis. Meanwhile, keep returning the theory – is the original explanation holding up?

    2. Dropping heuristic evaluations parallels the seeming decline of rigorous and dogged usability testing. Expert review with a cognitive walk-through suits our new leaner UX sensibilities.

    5
  13. 25

    Hmm, SM is eating my comment!

    Here it is as a link: http://markable.in/file/5a1e8bd0-f23c-11e1-95f2-984be164924a/

    0
  14. 26

    Great article!

    0
  15. 27

    How nice to see you Marcin on SM :) Really nice article. I always enjoy your presentations too ;) Greetings!

    0
  16. 28

    Appreciate the research and findings.

    Recurring theme of your article is desire for more “time for creative work and research.”

    Maybe I mis-read, but it sounds like wanting to get [close to] right design the first time. There is another approach to save time: “fail fast.”

    Admit before beginning the practical impossibility of starting with a good design. Create a bad one quickly, then just fix the worst parts based on critique (rather than “surprisingly … important” approval). Then more critique … rinse & repeat until the clock has expired.

    Remember the goal is not creative work and research, the goal is a highly usable product. Research in tiny bits (just to fix a couple of the worst parts) rather than big chunks doesn’t consume big blocks of time. Creative work is still 99% perspiration.

    2
  17. 29

    Bardzo interesujacy artykul, dzieki za info!

    0
  18. 30

    4 years have passed since i graduated the design school, and more than 8 since my very first contact with articles and discussion about design barriers, and it is always the same depressing arguments, i thought it was a problem only on my country(Brazil) but, after reading design old articles from bauhaus, 60´s and 70´s, the point is always the same:
    “nobody care about us but we gonna save the day, but we just don’t know how”

    Today reading stuff like this just make me depressed. I kinda ignore this topics and go on,i´m not a millionaire or earn as much as my medic does, but i have a good career growth perspective.
    Whats the problem with designers nowdays? will designers ever smile someday?
    just accept we are not superheroes and we have a job just like other normal people does.

    3
  19. 31

    Thanks for shining a light on reality, when so much writing talks about ideals.

    I agree that lean usability methods are long overdue for another reason than budget. I’ve seen plenty of money for formal testing but most formal testing occurs too late in the process and is too clunky and unusable. The true benefit of lean usability is continuous usability starting earlier in the process.

    1
  20. 32

    your aproach towards the ux is straight, clear. I like it!

    1
  21. 33

    You suggest that people grab a version of the CS suite, spend a couple of hours on youtube and call themselves designers or even UX designers. There are “old posters” and “old fashion” methods out there that remind us about the roots of a process. The decision of when and how many of those steps depends only on your specific project and experience of course. Or, do you pretend to “cut everybody’s hair with the same scissors and in the same way”?
    It is not avoiding user research or personas or even skipping one or another step in the design process. It is about having plenty of cards in one’s hand to decide wisely which one(s) to use according to my budget, stakeholders, specs, etc. (btw, those are the real “trouble makers”, not an “old poster”)
    I think you are misusing the (thousand times) mentioned term UCD, when in the end what you are suggesting is a totally subjective (and in my opinion somehow egoistic) “MCD”.

    11
    • 34

      “You suggest that people grab a version of the CS suite, spend a couple of hours on youtube and call themselves designers or even UX designers.”

      Absolutely not. There’s not a single suggestion in the article that statement above is true.

      “Or, do you pretend to “cut everybody’s hair with the same scissors and in the same way”?”

      Nope. I present findings from a research. The article is called “The Real-Life UX Design Process” – because it actually shows a research on what is and isn’t used by UX Designers.

      And if anything I’d agree with you on that:

      “It is not avoiding user research or personas or even skipping one or another step in the design process. It is about having plenty of cards in one’s hand to decide wisely which one(s) to use according to my budget, stakeholders, specs, etc. (btw, those are the real “trouble makers”, not an “old poster”)”

      I’m affraid you misread me. It’s not an article about troubles made by an old poster.

      0
  22. 35

    While you can surely have a UCD process in place, it rarely becomes routine because people and their needs are different. Processes seem to keep designers behind a brick wall sometimes and designers block can easily settle in. Its imperative that designers are able to work freely for uber creativeness.

    Processes are good don’t get me wrong, I’m just not convinced they’re beneficial enough for designers to be worth it. Designers are naturally all over the place all the time, structure is not in our bones in the traditional sense (this is a good thing).

    2
  23. 36

    I wondered if you could provide some examples of “guerrilla research methods”? Methods/websites/resources of doing research on the cheap or free would definitely be advantageous for most designers.

    One of my main questions about UX design is why split the definition and role of a “UX” and “Web Designer”. Sometimes I read things that suggest web designers should be limited to just visual design but I find this very strange as being a web designer myself, I was trained in most UX methods such as wireframing, research, usability testing and the whole pyscological side of meeting a user’s needs etc / user focussed design.

    My other question would be if you believe UX designers should come from an artistic/ design background such as having qualifications or experience in graphic/web design/ art? It seems to me that if a UX designer is wireframing and defining the form, layout etc – effectively designing a page, they should without a doubt come from a web / interface design background.

    0
  24. 37

    Morgan Wadsworth

    August 31, 2012 8:51 am

    Love the article, it’s both timely and very validating.

    It’s easy to fall in to an organizations silo’d structure of roles and responsibilities where departments are protective of their skills and people and throw up walls that keep those inside sheltered and inclusive. These are the walls that you are expected throw your work over so that the sheltered group can do their thing and throw their work back over back at you or another group. Not very collaborative and in the end creates a very fragmented experience for the user.

    Tearing down the walls, getting everyone in the same room (not for a typical meeting) and arming everyone with markers and paper and asking them to sketch and participate does a number of things to improve the project landscape and your final product:

    1. You get alignment on direction and needs early from the right representation and personalities
    2. You spend less time designing what you think is needed or valued which means you are more focused (which is something I know I need).
    3. Inviting and including the Executive stakeholders (who hopefully feel compelled to sketch and explore) are now feeling tied in to where things are at, where they are going and can represent the project/initiative/program amongst their circles (I’m talking about the other people in the organization that can have a BIG impact on what you’re doing!).

    I know it will be clumsy journey in the beginning as this is a big leap for the way our organization has operated, and I know I have a lot of personal growth that needs to occur as well (after all I’ve been forced in to my silo a lot which can be a comfortable place to hang out), but I’m very excited about being a champion for the introduction and institutionalization of this UX process.

    Stoked!

    1
  25. 38

    For me this article sounds naive and communicate a wrong sight on UCD.

    I don’t think that there is one process which fits all projects. Neither the UPA UX process nor your new UX Design System can achieve this.
    The UCD lifecycle is a toolkit and for every project I have to decide which tools I really need to accomplish the best result for the client and their customers. I always understood the UCD lifecycle as ROI oriented. It’s just simple maths. What project is it? Is it about a simple website with 5 pages, an e-commerce site or a complete new application? What is the potential of the website? Is it just a website without a commercial background, an e-commerce site with a yearly sales over 20 Millions $ or an application which is used by 10.000 employees 8 hours a day?
    If you have an answer for these questions you can evaluate which tools are necessary and what is the possible impact of them.
    For further reading I suggest an article by Jakob Nielsen: http://www.useit.com/alertbox/expensive-usability.html

    If your research comes up with ONE “real-live UX Design Process” it’s just a hint how blinkered your research is. In my opinion you just interviewed designers with a similar client and project base.

    By the way… The wrong point on the UPA UX poster is that the process has a start and an end point. A real optimization process should be a never ending story, like it is symbolized by the DMAIC cycle (http://en.wikipedia.org/wiki/DMAIC). For every step and every round I need to decide which tools from my UCD toolkit I need.

    12
  26. 39

    Based on the comments it seems that many readers appreciated your points, though I am surprised that people didn’t know this inf before reading the article. It should come as no shock that an academic, theoretical map does not align to working reality. It should also be no surprise that communication of idea lays at the core of value creation.

    The fact so many here seemed unaware of some of the points made here shows the state of skill levels in this profession. Not until late in the comment roll did someone mention the role of behavior and psychology.. Many who have taken the title of UX design have no awareness of the real basis of the profession. Being a former CSS developer does not a UX designer make. This crowd may want to look to the world of product design and ergonomics to help better understand process.

    2
  27. 40

    Well that is comforting, on this, “We seldom perform user interviews…. Our user stories are sometimes created based on personas, which are hardly ever backed up with data. Field studies and task analysis are hardly used by any of the designers we interviewed.” Peter Merholz ‘pretty much always’ and Mike Kuniavsky ‘always’ do user research on a project (from Twitter). Let’s see what the others you cite come back with.

    How did you reach the conclusions that we “seldom perform user interviews” and personas are “hardly ever backed up with data” etc?

    3
    • 41

      I conducted above 50 interviews and there were more than Peter and Mike who always do user research. Please mind also that I didn’t quote nor Peter nor Mike in the article.

      Majority of my interlocutors claimed that user testing is not an usual part of their process. Not that they find user testing not important for the design. External causes sometimes make our design activities poorer that we wish them to be.

      This is the state of the field as observed in my study. If you don’t agree with it, I’d suggest rather than trying to look for a hole in the article, starting to promote user research across stakeholders (especially outside of the US).

      1
      • 42

        Thanks Marcin. I don’t believe your article is representative of current practice and some of your respondants clearly didn’t agree with your conclusion either so I wonder how you summarised your research and I wonder who else you spoke with.

        I have done UX design for more 20 years, with only 2 years working in the US and I have managed to engage with users on nearly all of my projects in this time. Not as much as I would have liked but to suggest that people doing UCD work seldom talk to their users seems very wrong indeed to me. OK in some situations, particularly in certain agencies, perhaps this is true. But on the whole I really don’t accept there is much value in UCD without the UC part of it. And to suggest that personas are a complete fabrication and are not based on research seems very poor.

        I struggle to believe that you have painted a picture of current practice.

        6
        • 43

          Carl – first of all I really appreciate your interest. I’m glad we’re having this discussion!

          Second of all of course some of my respondents won’t agree with the conclusion. It doesn’t represent the whole – just a majority of voices that I’ve heard during in-depth interviews.

          Believe me, if I wouldn’t be concerned by the result I saw in gathered data – I wouldn’t write this article. I prefer to describe ‘the real-life’ even if I don’t agree with it, than pretend everything goes according to the book. Why? Only if we deeply consider how the reality looks alike, we’ll be able to change it.

          Please mind that the situation of UX Designer working for years as a consultant (especially with highly respected name and unquestionable authority!) is much different than the situation of UX Designer in a “just built” in-house team. You (as well as Mike, Indi and Adaptive Path [I’m not sure how’s Peter’s current company operates) are hired to do the research and build the design on it. And it’s absolutely great! That’s the way it should be.

          (Though it’s interesting that Mike mentioned on Twitter that even he’s jobs has never as much time and money for research as he would like to see.)

          We can’t forgot though about other career paths, which leads through environments that don’t welcome extra expenses on user studies. I wouldn’t blame designers working for such companies for trying to find leaner way of doing UX Design.

          Damn…I was exactly in this situation couple of years ago. Very small budget for user studies, very rapid development cycles. I used power of GA Event Tracking and Multi-variable testing. Today I’d certainly add guerrilla research to the picture, which in the past I wasn’t particularly fond of (I used to be very strict when it comes to methodology).

          So Carl, my point is: it’s better to consider what works and what doesn’t, even if not everything is pretty and really think through our problems. Who knows… maybe we’ll come up with a solution.

          I just tried to picture average of processes that people told me about.

          If you don’t like it – that’s a good start! Let people hear your voice and teach them how to do more user research in tight budgets. I’m serious.

          And about the value of UX Design without user research (or any other part of the process!) – I’d say we should always judge UX Designer’s work by performance of its final result – a product, a service, NOT the process.

          Performance should be measured in real environment and described by SMART metrics.

          One more time – thank you very much for your interest in my article!

          1
          • 44

            “I’d say we should always judge UX Designer’s work by performance of its final result – a product, a service, NOT the process.”

            ‘nough said.

            0
  28. 45

    Very useful article Marcin, thanks a lot!

    Unfortunately, several early agile adopters misinterpreted the documentation part of the manifesto, and said that there was no place for documentation in agile. Actually, any useful document is welcomed in agile – I wish our designer would create more drawings, wireframes and mockups -, only those are not welcomed which don’t bring any value: e.g. a user guide for a web application or a detailed schedule for the upcoming 3 years.

    2
  29. 46

    You mention that most designers are doing benchmarking and trend analysis. Can you explain what those are? Are they forms of competitor analysis (what others in their space are doing well, and where there are opportunities for them to gain an advantage?)

    3
  30. 47

    also: there is no checkbox on this blog to say i want to receive email, when further comments are made, or my comment is responded to.

    could this standard feature be activated?
    (or if it is, help me out, and let me know how-to) thx

    0
  31. 48

    I love this article – thank you. I’m typing this as I sit underneath the UCD wall of shame, myself. I put it up yesterday after much deliberation. For one, I didn’t want everyone to see all the things we could be doing but aren’t. As a ‘UX team of one’, I was feeling a sense of guilt for not having yet launched some of the steps in the ideal UCD process. I also didn’t want to look unhip and un-agile. After all, with words like lean and iterative flying around, it must be entirely silly to have a set process poster hanging over my head. I did end up hanging the poster however. While it’s not applicable to every project I work on, it’s a helpful reminder of the kinds of things I could do at each stage of the project, so I can ask myself whether there’s anything I’m missing, or any helpful tools that I’m not using. And so I can expand my approach and tailor it to what the project needs everytime. As an avid procrastinator, I’ve accepted that every checklist is destined to be only partially completed, and so I treat the poster as a colourful list of suggestions, rather than a menacing supervisor. After all, there’s enough stress in trying to explain UCD to clients to be scared of a poster :)

    2
  32. 49

    Hi Marcin,
    Thanks for a great article! We’re actually doing something quite similar at work at the moment- understanding our own design process (everyone does things differently) and then hopefully establish a common UX design process which we could all embrace.

    I’m particularly interested in your approach and the in-depth questions you used to during the interview. Can you please share them, if possible?

    Thanks!
    Christina

    2
  33. 50

    I can understand and sympathize with you on the costings. As a business owner that pays out a lot for UX internally as well as for clients, and honestly I know some of the work can be daunting, and it can be tempting to try and skip bits here and there, but did the business never think of standardizing a few steps?

    Essentially you are then following the process, but “automating the automatic steps, so graphing data into charts, should be fully automatic, especially in a world with all the raw data we have floating around. It is cheaper to have a machine download data on analytics through the Google API’s, generate charts and meaningful statistics and honestly these are the worst areas to have humans in, as they will undoubtedly try to put a spin on work in their favor.

    Deploying the Google heat maps, A->B split testing and most of the more laborious tasks of UX can all be automated including form field inputs, wire-framing and monitoring action data (part of me wants to say sales but you my not always be charged with directly driving sales). The point is these can all mostly be done using collections of frameworks, that provide common alternatives (as UX design ultimately boils down to something working or not working)…

    IT just seems to me that when left standing in a hole, instead of trying to build tools to get out of a hole people, companies, entire industries either keep digging hoping to get to the other side, or have a nice long cerebral think about why they are in a hole without doing much about it. Sure occasionally the rain will fall heavily enough for you to get closer to the top of your metaphorical hole, or in some cases, entirely reach the top. Then you can all float out of the nice big hole you have made, but is it not better, faster and brighter to consistently try to build your way out.

    Anyway glad to see you have started with your tool, nice article.

    1
  34. 51

    I am surprised but also quite pleased that you do not mention ‘Design Thinking’, a phrase that is supposed to focus on the user. As a designer I have found out that many authors who write about it are not designers, yet they profess to be experts in DT.

    0
  35. 52

    Would love to watch the vid, but the link is private :/

    0
  36. 53

    Ruben Villanueva

    May 26, 2014 10:33 pm

    Insightful post. I couldn’t read it all but spotted the main sections of it. I also practice a guerilla type of UX design however I always find myself going back to the basics of user / usability testing for my mock-ups and prototypes where actually the real user is the most important factor in order to design a system that meet user requirements and tasks. In my experience as UX design I tent to pay little attention to what other designer or stakeholder have to say as they already know too much about the project so the iteration remains between the user(s) and myself.

    0
  37. 54

    Garsh, these kind of articles drive me a little batty. Of course fiction is far more idyllic than reality. But if we didn’t have solid process models to follow we’d be lost. Someone once said that the greatest thing UX and UCD brings to the software industry is PROCESS. I’m a big fan of knowing what parts to use when, and not wasting time on steps that are unnecessary for a given project – but you’ve gotta know what those possible steps are to apply the correct methods at the right time. You can’t throw the poster out with the bathwater.

    Have I ever followed every single step in my ideal UCD process verbatim? probably not. But that’s why we get paid for knowing the correct application of each methodology. Does it hurt for the uneducated and newbies to UX to see posters like this and learn from them? NO. That’s what they’re for. It’s how we teach people what we’re capable of, whether we’re given the time and resources to live up to that potential or not.

    If you went into a restaurant and there was no menu, is that preferable? We need to know what is possible, so we can reason through what’s necessary.

    0
  38. 55

    “The UX Design System” video is set to private. It’s been two years so maybe you’ve changed it. Is there an updated video link?

    0
  39. 56

    I’ve been a designer for 20 years. I liked it back in the day when I decided how it all turned out with just the client. Everyone says it saves money to have more meetings, pay more people to be involved, and a longer drawn-out process. I can make a UCD without all that. What do you think? What’s the point?

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top