Tagged with: ‘ui’

Posts: 6

Questions to ask your design work

Last month I spent some time updating my portfolio. As a product / user experience / web designer, it can be quite tricky to present your work to others.

The rock star visual designers of this world can get away with presenting screenshots of their stunning visual work — job done, money due.

But if your day-to-day consists of making user flows, interaction designs, napkin wireframes, trade-offs, A/B tests, and minimum viable products, then you — like me — need to do a bit more groundwork to do the show and tell properly.

It’s not so much the what, but the why and the how.

With this in mind, I decided to structure my portfolio around the questions I ask myself when looking at other products and services:
A user experience, product design portfolio layout

1/ What was the context?

Was this a piece of work for a fast moving startup or a 100 year old family business? Setting the context lays some good foundations for answering the questions around what you did and why.

2/ What problem were you trying to solve?

The cornerstone of successful design projects, is making sure you’re solving the right problems.

In this section of my portfolio pieces, I found it useful to pull apart the problem I was hired to solve.

Sometimes the problem definition is a bit blurry i.e: Do we really need to make the sign up process faster? Or - to convert more prospects - should we enable users to access features without committing to signing-up first?

3/ How did you design the solution?

Here we deep dive right into how you designed the product / interface / solution.

Unpack how you approached things. Show rather than tell. Let us see what you made.

Did new insights emerge as you moved through the project? If so, lay them out here — tell us how you responded.

4/ Review the above

The final section of the portfolio answers:

  • How did it go?
  • What impact did the solution make?
  • What happened when your work reached customers’ hands?
  • Can you surface some feedback or data that points to show your solution is working out?

Arguably, the biggest thing you bring to the table as a designer is your ability to render an optimal solution — and answers to these questions go a long way in revealing how you do that.


Same Same. But Different.

It’s Sunday, late morning, and I’m right in the middle of cleaning the bathroom. In the other room I hear a frustrated girlfriend struggling to find accommodation on - lets say - website X, for our trip to the Amalfi Coast.

Complaints flying left, right and centre, vented in a tone that kind of suggests that this is all my fault:

  • “Why won’t this?”
  • “It won’t let me!”
  • “I keep loosing my tab when I go to trip advisor for reviews!”
  • “I hate this”
  • “Why can’t it show me what’s available on the dates that we’re going”
  • “Oh FFS!”

At this point I’m scrubbing the bottom of the shower. The smell of bleach is intense and my trainers squeak on the floor as I scrub back and forth. Before I hear the next complaint come in, I stop and shout - “try AirBnB?”

“Ahhh! I can’t use this useless website anymore.”

“Try AirBnB!” I shout.

No reply…

30 seconds later:

  • “This place looks gorgeous”
  • Then there was laughter “this guy’s review is hilarious… ‘It's a great place to unwind and get away from it all. Especially given the wifi and flatscreen TV doesn't work’ haha”
  • “I’m loving the ones that look good, ok”
  • “we can go through them later“

3 minutes later, “I’ve found somewhere! Let’s book this one!”

Same problem, solved differently

AirBnB and website X offered the same thing, that is: A product that helps you find, compare and buy accommodation for your travels.

One had concentrated on designing a delightful user experience, the other clearly has some work to do.

What fascinates me though, is the impact that poor design can have on someone’s Sunday morning.

Put another way, how important our work as designers is.


Product Design Process

When we have a new product idea (and are lucky enough to have the skills and tools to execute on it), it’s often more than tempting to jump in with two feet and start building the thing. Before we know it, we’re pitching the hows before whys and problem solving becomes a battlefield of miscommunication. As a result, our product concept becomes more complex and less focused.

Over the last few weeks, I’ve been investing a lot of time and energy into a product design process that we’ll be using for an upcoming project.

I insisted we made investments in our process and put this case to the team:

We’ll Make a Better Product

The main reason for using a product design process is ‘to make a better product’. To query our definition of a better product: a product which outperforms its competition by solving its customers’ problems in a more simple and effective way.

We’ll See Where Value Can Be Added

Distilling the big problem that our product is solving into situations will help us visualise all the moving parts and figure out where value can be added.

Ryan Singer writes a brilliant piece on situation value:

Suppose a team is building a “file versions” feature. Two situations define the value differently and lead to different designs.

In one situation, a person catches an embarrassing mistake in a proposal and wants to know who to blame. In order to do this, they need to see information about intermediate versions. They value the product telling them who made what changes and when.

On the other hand, consider a situation where they want to send the latest version of the proposal to the client. They don’t care how it got to its current state. They just want to send the correct file. In this case intermediate versions have no value. The user just wants to know where the latest version is.

Different situations = different values.

Defining situations will align us as team and conversation will be more constructive and focused on the task at hand; getting users from A to B.

In the absence of code we can quickly iterate through our best ideas, fitting all of the moving parts together. This will maximise our potential of designing a product concept which is simple, useable and more effective in its approach.

We’ll Sing from the Same Hymn Sheet

We’ll waste less time and energy mis-communicating and voicing logical speculation. Instead, we’ll be solving real problems based on real situations.

We’ll know the right time to discuss problems and when it’s right to discuss solutions. Better still, we’ll be contributing ideas from our respective areas of expertise, which will open up new opportunities and unblock us.

We’ll Think Conceptually

Freeing ourselves from code will help us to problem solve in a more abstract way. Code is high fidelity; like cemented bricks. Better to think solely about the product in its conceptual form with something low fidelity, like paper mockups.

The beauty of problem solving on paper is that it’s quick and easy. We don’t need to be artists to present our ideas to each other. What’s more; we can quickly hash-out numerous iterations of a design pattern or technique and pitch them against our view of a better product.

We’ll Build a Better MVP

Once we’ve formulated our product concept, we can outline features that we want to exclude for 1.0; this will form our minimum viable product (MVP).

We’ll know that the MVP we’re building, is in fact, the foundations to our product concept. We’ll waste less time as everything we build will count towards the whole. We’ll loop through less iterations as the UX will have a solid direction, cemented on real world problems.

So far…

The process has already helped us in the areas above. We’re still learning though and adapting to a new workflow is always daunting. We’ll put the process through its paces a little more and I’ll share it on here once we have something to show how effective it is.

In the meantime if you’re working on software projects and care about what you ship, I’d suggest you checkout Rick Hickey’s talk on design, composition and performance as well as Ryan Singer’s post on the Vital Elements of a Product Design Process. Both have been central to designing our product design process.’


What’s next?

When we hit the bottom of your web page, what do you want us to do? Where should we go next? What are other people saying about this service? Should we get in touch with your team or look at the tech specs for this ground-breaking new product?

Too many websites fail to answer these simple questions.

Think about it: It’s a bit like visiting a supermarket with aisles that lead to dead ends. You either walk all the way back up the aisle, or you loose interest altogether and are forced to use the fire exit.

When we reach the end of your web page, show us where to go next. Better still, you know where we are, so show us other things that might be of interest. You’ll be amazed at how much longer we stay and how much more we’ll learn about you, your story and your products.


The Future of Interaction Design

Check out this video that sheds some light on what we can expect from the future of interaction design.

Lots of discussion around the 'internet of things' and how user experiences will become less intrusive and more natural as this area matures.

I guess this dovetails with my analogy that we're moving further and further away from abstract computer interfaces. To piggyback on Luke Wroblewski's paradigm, we can see where we're heading by acknowledging the big interface developments:

  • The Command Line Interface
  • The User Interface
  • The Natural Interface: interacting with the content (i.e. pinching your photos to zoom) or thing (i.e. switching the lamp on) itself.

I think that video might have been the nudge I needed to get myself along to the next Maker Night.