Tagged with: ‘process’

Posts: 5

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.


You produce results: Learn from these

It’s nearly been a year since I joined Fruitful - a fintech startup that’s working to rethink how savers save and how borrowers borrow.

Since then we’ve been through a significant product redesign, a complete branding overhaul, a successful soft-launch and a customer response that has more than overwhelmed us. With customers investing with Fruitful from all over the globe, it’s clear that people are in search of an ‘alternative’ that offers fair interest rates, secured lending and the flexibility that we should expect from a modern investment product.

So as we venture into 2015, I thought I’d share a handful of the lessons that I’ve learned and have considered tattooing to my forehead.

Mostly product focused, take from this what you will:

Integrate Around Concerns

When working with a team of designers, developers and content people, there’s always a temptation to separate tasks by role, such as a ”design” todo list and a ”programming” todo list.

The problem with this approach is that it’s difficult to assess progress from separate to do lists or issue backlogs. On top of this, there’s an increased operational risk. Since the QA effort stutters, stopping and starting as each role’s to do list is completed, you run the risk of failing to test the feature as a whole.

Learning from this, we’ve formalised a workflow that integrates arounds concerns. Instead of organising around roles (e.g. design tasks, programming tasks), we organise around areas of concern (e.g. registration form, email receipts). As Ryan Singer puts it:

Marking one piece “done” is powerful because it requires design, programming, support and review to integrate around a specific point in the product.

Whenever a list is finished, it shows a piece of the product is ready to review and mark ”done”. It feels great to know one part of the product has no remaining contingencies. It’s ready to go.

Minimum Marketable Product

Give that I:

  • joined the project just after its inception and
  • had limited experience in the mortgage market and
  • was (initially) unsure of its legal and regulatory commitments

I failed to ask some important questions about minimum marketable product (MMP).

And yes, I prefer MMP as it underscores the importance of building something that is sought-after, by customers, (marketable) vs. something that is viewed merely as feasible, by the company, (viable).

On top of this, MMP forces you to:

  1. Think about the important areas where you should adding value (i.e. your differentiators) in conjunction with:
  2. Working hard to develop those areas, so that they reach a high level of finish, giving you a better opportunity to win the hearts and minds of your customers.

Given the choice, I’d always favour a good job of half, than a half-assed job of all. Much later than I should have, I noticed that as a team, we were stretched and chasing our tails to reach our fast-approaching launch date.

After some belated conversations about the product’s essentials, and a hash through our priorities, we were left with a much more slender view of our MMP. As a result, we were able to achieve a higher level of finish with features we developed, we were less stretched, and we shipped quicker.

In short: dream big, implement small.

90% + 90% does not equal 100%

The ninety-ninety rule lassoed us a number of times:

”The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Tom Cargill, Bell Labs.

In short: be very careful that you do not underestimate the time, effort and energy that the remaining 10% will demand from you and your team.

Deadlines are hard to reach. And they’re even harder when you mis-judge the magnitude of your plans.

Go broad before you go narrow

Common talk in the world of human-centred-design, but this is useful in most walks of start-up life.

When you have to make a decision, go far and wide with your ideas, no matter how daft or bizarre they sound. Superglue the Devil’s advocate mouth together while you go broad with your thinking. You never know what inspiration you might draw from this left field, brainstorming effort.

This method of thinking has helped us overcome some real challenges and produce far superior solutions and ideas.

Effective concepts often draw on multiple sources of inspiration and thinking, and this process will help you along your way.

Finally: on Venture Capital

“It’s all about burn rate, about burn rate, slow spending...

Fingers crossed I’ll find more time to write and share what I’m learning in 2015. I hope you do too.


Shortcuts You Can’t Take

Last month Sage approached me asking if I could write an article on marketing for their small business community.

To narrow the context a bit, I concentrated on marketing websites. The outcome of which I'm really pleased with. The short post offers an insight into my past 5 years of researching, designing, building and iterating marketing websites for clients. What works / what doesn’t; all brought to life with three tiny case studies from a few of my longstanding clients.

Entitled “The Shortcuts you can’t take” the article points out how businesses can contribute, in volumes, to their bottom line by concentrating on adding value through content, design research and website investments.

Profit gives you freedom. Fingers crossed this short piece will help you along your way →


Our Duty

Firstly, think about what your pages do, not what they look like. Let your design flow from the services which they will provide to your users, rather than from some overarching idea of what you want pages to look like. Let form follow function, rather than trying to take a particular design and make it “work”.

For us wonderful folk who make websites, it’s our duty to read John Allsopp's seminal A Dao of Web Design at least once a year. For an article that was written way over a decade ago, many of those points still offer so much significance today.


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.’