🧩 Process vs outcome: what is more important?

🧩 Process vs outcome: what is more important?

What do you look at when checking out a design case study?

This week I was going to talk about gamification in UX. However… while I was giving feedback on a beautiful Case Study on Discord, I was met with a tad of resistance when I stated that outcome was not the most important part of a Case Study, but process was.

Instead we’re going to talk about:

⚖️ What is more important, and why is this debate even a thing?

〰️ What do I mean when I say “process vs. outcome”?

🤯 So, should you not create cool Dribbble shots?

So… I thought I’ll just pour my heart out about what I mean… and maybe somebody can give their 2 cents (I do care about that part a lot)

So here is what I mean: whether you are a junior designer or a senior in your field, a company who’s looking to hire you doesn’t know you or what they can expect from you.

I gave the analogy of having someone building me a house from scratch. If that someone (you, the designer architect) can’t talk about what you did to build that house, how would I know that you didn’t just buy a prefabricated home, or that your 4 year old niece didn’t design the plumbing of the building.

Another analogy would be a math problem. How many times were you not able to turn in your paper because you knew the answer but couldn’t explain it…

To finish the Discord story, eventually we realized that we were agreeing all along, but it still got me thinking about all these Dribbble shots and amazing looking UI projects nobody will ever actually build…

⚖️ What is more important, and why is this debate even a thing?

Well… that’s a great question.

You see, design students often tell me that they look forward to when they get to “actually design” the product. Meaning, they look forward to the UI part of their project.

Not gonna lie, that statement always catches me by surprise. That’s because in my book, every single step I take as a designer, is part of the design process. From the thoughts I have around my morning coffee, to the choice of pen I am making when doing wireframes (highly recommend sharpies, btw. The thicker, the better). Everything matters.

Further down the line, once they have gone through the entire process, and can have a first impression about everything they just did, they usually come back and tell me that they actually enjoyed problem solving a lot more than they thought they would. And I am relieved when I hear that.

Don’t get me wrong… nothing against being a UI designer, they are absolutely necessary, and I wouldn’t dare say that there is no room for designers who specialize in UI.

However, there seems to be this misconception that UI can stand on its own legs, and that is almost never the case. UI is what makes designs user friendly, UX is what makes them usable. And I know, some purist designers will come at me because we could argue that this statement can be argued with, and that’s precisely the point:

UX and UI are sides of the same coin. That image of the iceberg, where UI is what you see and UX is what’s under the surface of the ocean?

Focusing purely on the aesthetic of a product will lead us to an end result that will likely prove to be over-engineered. But… wasn’t the point of design (UX and UI) to simplify processes?

Good UX and good UI go hand in hand. Is one more important? Not necessarily. I will say though: Good UX includes good UI. Good UI doesn’t always give you a good UX.

〰️ What do I mean when I say “process vs. outcome”?

Most designers will agree with me when I say “you are likely not going to use every tool in your toolbox for every single project you work on.” Some projects will require certain design exercises others won’t, and that’s okay.

The key about design is not to know the order in which the elements fit in the toolbox, but to be able to accurately pick which one you are going to need in a given scenario.

But picking a tool is only 30% of the entire journey. After picking the tool, you also should be able to use it effectively, and explain your rationale:

• Why did you choose this tool
• What insights did you gain from it?
• What are your next steps based on the insights you received.

When working with case studies, this almost always translates into a heightened necessity for storytelling skills. In the discussion described above, my counterpart provided me with this Case Study: Ellen Covey’s The Beakery.

And… Ohhhh My Goodness! This case study is gorgeous!

Note that she starts out the case study with a personal story. She tells us how she hatched 6 Quail chicks and the problems she encountered. Amazing to draw you in, almost like a movie. In addition, throughout her case study, she employs third person narratives to refer back to her personas and breaks the amount of text with many visuals and appealing yet simple scrolling behaviors.

Voilà! Amazing recipe for a beautiful case study.

Her ability to mix the tools she has used with a perfect balance of Design Rationale and Storytelling has given her case study a story-like narrative, which is so, so, so valuable! Engaging, informative, concise.

But does this put her UI in the shades? Absolutely not! It actually paves the way towards it.

🤯 So, should you not create cool Dribbble shots?

You absolutely can! There is nothing wrong with designing a nicely animated sequence of screens. Keep in mind though: these projects are usually delightful to watch, annoying to use and painful to build.

Writing a compelling case study that goes with the Dribbble shot (or viceversa) is definitely worth it, and will give your designs more depth. A case study that showcases your ability to defend advocate for your work, which is all Design Rationale really is.

I’d love to hear your thoughts in the replies (which puts together hearing, thinking and writing, isn’t that amazing?) So, please let me know.

Talk soon,

-D.