I work predominantly in agile teams using a Lean UX approach with concurrent streams of tactical and strategic design and research, supporting the development team with the stories being delivered in the current sprint while looking at stories a sprint ahead, and epics further out.

Often developers will want advice on user interface design and surprisingly my response will be that I don’t care about the details.

The thing is, I absolutely do care about the details of user interface design and usability, but there’s little value in sweating the details for screens and workflows that have yet to be validated at a higher level. When you’re working with an agile methodology everything is tentative; developers are building and deployment increments that you may have have had no involvement in validating and designing. And that’s okay. When there’s one designer and half a dozen developers you can’t afford to be a bottleneck nor impede velocity by forcing a linear workflow.

Sometimes the details are vital to demonstrating the viability and desirability of a feature or screen. Often they’re not. There’s little point to getting bogged down in form design, interaction and typography until you’re confident that the feature is likely to survive validation and testing and worth investing more time in refining.

The more time the team invests in refining the presentation of user interfaces that haven’t passed validation with customers the more it hurts when those screens are demoted or discarded from the product.

I’m not necessarily talking about technical and design debt, although that’s often part of it — prototypes are intended to be thrown away, MVPs are not — but focusing on activities that will deliver the greatest value and impact.

Hold your ideas lightly and be willing to let them go so unsuitable design and features don’t persist in the product because of your ego or a sense of squandering the team’s hard work.

If the team has thrown together a corrugated iron shed to test whether the size and placement of the shed is suitable, there’s no point spending all weekend painting the shed because it’ll likely be pulled down and set up somewhere else … and if you’ve put in the effort to paint it, the team might be reluctant to touch it.

As Tony says in Scarface (1983) “You gotta make the money first. Then when you get the money, you get the power. Then when you get the power, then you get the women“.

In other words:

Don’t get bogged down in screen design until you’re sure you understand the purpose of the screen

Don’t get bogged down in determining the purpose of the screen until you’re sure you understand the suitability of the workflow

Don’t get bogged down in the suitability of the workflow until you understand the relevance and market need for the feature

Don’t get bogged down in assessing relevance of the feature until you understand the scope of the product

Don’t get bogged down in the scope of the product until you understand the fundamental problem you’re trying to solve, and for who

Start from the bottom and work upwards, and don’t skip a step.

If you enjoyed this article please share it with your friends and colleagues.

Some designers lean more towards the artist/genius side. That’s not me. I believe design is more of a craft like cabinetmaking that straddles both art and engineering, function and form.

My goal is to be able to justify every design decision and trace it back through user insights from research, collaboration with stakeholders and my team, and heuristics back to high-level requirements and the vision for a product or service.

It’s not always possible and sometimes it comes down to a flip of a coin or personal preferences; when that happens I’m happy to admit that to my team or client and let them have an equal vote if they want to contest the design.

But I do see that this mode and attitude leads to designs that lean towards “barely enough”. While I might have had great success in encouraging clients and teams to think creatively and explore ideas at a conceptual level, when it comes down to implementation it tends to be too heavily influenced by technology – specifically what the chosen technology can do and what it looks like out-of-the-box.

Trying to make tasks easier for users to complete, to proactively push information to them and let them cut corners or take shortcuts … these are often a battle, and it shouldn’t be.

Here’s a concrete example from Atlassian’s Confluence:

If I were a designer involved with Confluence I’d want to provide users a way of requesting access to the page or space. From a user task and goal perspective they can probably achieve this as they’ll know something about the page they’re trying to access and can find someone involved who can dig up the space admin who can then make a decision. But a text field “Why do you want access” and a submit button would be so much nicer and make their lives easier.

Heck, I’d just be happy if they provided the name and email address of the admin, that’d save a lot of time and frustration.

Trying to tie such recommendations back to subjective and ambiguous brand values of “friendly” and “helpful” can be a tough sell. If you’ve set the expectation that you back up all design with evidence and then suddenly you’re trying to get things through the door on clouds and fluff then of course it’s no surprise when getting that last 10% to finish the product than ship it rough sawn is like pushing shit uphill.

It seems to me there’s an opportunity here to market ourselves (or at least myself) as curators of great user experiences, that it’s more of a package than grains of sand that development teams feel they can ignore.

You can’t have us bake a cake and then not let us put candles on it; what sort of disappointing birthday would that be?

It feels necessary to counter the strong and often overwhelming appetites from teams and clients to do less, to see what they can get away with not doing, minimising custom code and keeping things simple, easy to test, easy to deploy, and easy to upgrade.

Their concerns and motivators are of course all valid but as Normal Modes’ UX Maturity Model [PDF] states “UX is seen as a zero-sum game versus technical imperatives and business objectives”. That’s just a common perception in immature organisations and teams and not reflective of how UX and development can work together to deliver great results, not just average, as perceived and determined by users and the market.

If you enjoyed this article please share it with your friends and colleagues.

In email signature blocks and documents I typically refer to myself as a Senior UX Designer.

Is it because I have subordinate designers who directly report to me? No, and if that’s what it was then I’d probably opt for Lead UX Designer. Is it because I’m old? No, I’m thirty-three although I have been working in IT since 2000.

So why a senior designer? Isn’t that a bit wanky?

Well, yes a little bit; sometimes I shy away from the prefix. I much prefer to demonstrate my value rather than attempt to assert it through a title on a business card.

It’s more a posture, it’s a memo to myself that I’m not here to be handed requirements, draw wireframes and log usability defects in JIRA.

To me, being a senior designer is primarily about design leadership. It’s the next rung up from doing design to teaching design, transformation and facilitating the delivery of design services through user-centred design maturity.

Can anyone be a senior UX designer? Does it just take experience? If I deliver 20 projects can I then call myself senior? Not in my book. Leadership, negotiation and strategy are skills additional to the base set of competencies for UX designers.

Yes experience is definitely part of it but so is a tenacious attitude and enthusiasm for improving the way organisations work and deliver or improve digital products and services. To not be the only person with empathy for customers and users and not even to persuade others empathise once-off but to invoke a culture where other people are asking the questions and challenging assumptions that you normally would have to.

Anyone can learn those skills and some people might have those skills and then learn UX (although it might be strange for an inexperienced UX’er to describe themselves as “senior” when they’re fresh out of General Assembly).

Champions fight on behalf of others. Leaders encourage and equip followers to fight for themselves … and maybe introduce some new toys and tools.

If you enjoyed this article please share it with your friends and colleagues.

The follow is based on personal experience and anecdotes and should not be used to inform design or business decisions about e-commerce.

It seems many smaller e-commerce businesses adopt the position that “Shipping costs what it costs and we just pass that onto customers” without considering how much revenue they could be losing.

Lower shipping from another retailer

An obvious example is earlier this week when I wanted to buy a high-quality English Haws metal watering can; one retailer wanted to charge me $36 – I enquired about it and got a sound explanation which made sense but didn’t persuade me to place an order with them, which should have been the aim of their response:

All shipping is charged on the greater of the cubic weight or actual (dead) weight. Watering cans have a cubic weight 15-20kgs, where they only weight between 2-3 kgs. We simply pass through the cost based on Australia Post’s eParcel rates.

Instead, I went with Peter’s of Kensington who charged me $9 for shipping.

Free shipping

Then we look at a retailer like Book Depository who offer free worldwide delivery. Not having to pay a shipping fee to buy books has changed my pattern of buying behaviours.

Instead of maintaining a shortlist of books and then placing an order every few months I just order when I want, sometimes placing orders just a week apart because it doesn’t cost me any extra.

I skip the stage where I cull my shortlist and instead can place orders spontaneously with no financial repercussions, so the upside for both myself and the retailer is that I order more books.

Tiered shipping rates

When I ordered some sharpening stones from Lansky in the US there was a shipping cost increase when the order went above $100 so I spent twenty minutes moving products in and out of my cart and whittled it down to come under that price point.

It’s completely irrational because if they just had fixed the shipping at the higher cost I wouldn’t have cared. But because I could save a bit on shipping I spent the time to do so.

Rewards and coupons

Another thing that alters my buying behaviour are rewards programs. At Timbecon you get a $20 voucher for every $500 you spend, but the vouchers are only issued once a month so if I want to place an order and I’m expecting a voucher I put it off until it’s issued.

Their shipping costs are low too, just $10-15 but that’s enough to stop me placing orders as needed and instead maintain a shortlist in my shopping cart for weeks until I feel like I’ve got everything in there I want and have excluded anything I absolutely don’t need … and that largely comes down to the shipping cost which is ridiculous as shipping sometimes represents as little as 3% of the order.

If shipping were free I would have ordered more products, more frequently.

Fuck it I’ll pay anything

There’s a Spain-based retailer who charges $60 express international shipping. That’s pretty high, but I’ll pay it because it’s still lower than any single one of their hand-made products (even though shipping can represent a full third of the cost of the order).

For those products it’s an emotional decision; I want what they sell, it’s the only place I can get it. I basically shut my eyes, hold my breath and click Place Order.

What really feels wasteful is when shipping costs more than the product, like when I paid $10 to ship something from Hong Kong that cost 99¢.

I think many businesses don’t consider the influence that shipping costs and rewards programs have on customer’s decision-making about placing orders.

If they did and implemented or perhaps even revoked rewards programs or offered different shipping costs including partially subsidised shipping then they could potentially increase their revenue and profit.

I know many businesses don’t move the scale required to qualify for low courier rates and for many simply passing on the costs of shipping works for them.

But I don’t think it should be the default. It should be a considered and deliberate decision made in the best interests of the enterprise to maximise cash flow and profit and I think in some cases incentive and rewards programs may actually be detrimental.

I have been the first UX hire for three-quarters of Australian organisations I’ve worked for in the past five years. Chances are you’re either not looking to hire a UX designer and even if you are looking to bring your first designer on-board then chances are you’re not quite sure what to do with them or what they can do for you.

Is this typical of other Australian UX designers’ experiences? Or do you find yourself more often than not employed in organisations that are relatively advanced on the usability maturity model [PDF] with an established and deeply embedded UX capability?

If you enjoyed this article please share it with your friends and colleagues.

The research

Johannes Hattula and his co-researchers at the Imperial College London observed in interviews with marketing managers that when primed to have empathy for customers they then went on to express preferences that were actually ego-centric and not from the perspective of their customers.

That is, people who believed they were being empathetic were actually less so, and would likely make decisions that aligned with they wanted – which would obviously have negative consequences for the desirability, market fit and adoption of products, services and brands that those marketing managers were responsible for.

Steve Jobs

I say “obviously” but I should be cautious because Jon and Chris go on to talk about Steve Jobs at Apple, who on the surface appeared to be a strongly ego-centric leader and yet led the company to runaway success.

In their podcast:

One thing that this brings to mind – and I think we could have an interesting discussion about this – is the whole idea of Apple under Steve Jobs versus Apple today. Steve Jobs I think, and right or wrong, you could probably view him as fairly ego-centric or ego-driven at least. But yet he seemed to also understand users or user behavior or at least you could say he was pretty savvy about what sort of customers he could appeal to with Apple products.

So is being ego-centric necessarily a bad thing? First, it depends on whether the observation about Steve Jobs is correct, and whether it’s as simple as drawing a direct link between Jobs’ ego and Apple products.

One of Jobs’ most important skills was his ability to work with and promote loyalty within his team of experts. Sure, Jobs was bombastic, but he also knew the importance of inspiring people to achieve the company’s lofty goals.

Saying No is critical to good design and engineering. Without a confident courage backed with informed conviction, products can lack clear definition and purpose.

Where does empathy fit in?

There’s some argument that caring too much about users can lead to uninspired, mediocre products that are functionally sound and useful but are missing a soul, a vision.

And now research shows that even when we think we are caring about users we may not be, certainly when we’re going with gut instinct instead of empirical data.

Jon and Chris encourage designers to do their homework and share their data so people can get on the same page and make informed decisions about what users want. Empathy is then an attitude, not a feeling. Empathy in design is a willingness to put aside your personal preferences and work with the preferences of others.

Once equipped with that insight and data your team can then be self-referential, cross-checking decisions and assumptions to cancel out bias:

It wasn’t actually confirmed in their research but based on what their findings were they thought that maybe doing some sort of team decision-making type of activities like brainstorming this might help alleviate the problem because having more opinions on the table might reveal some other internal biases within the organisation.

Do we focus too much on data? Too much on this concept of empathy? Is there room for ego? Do we make excuses for ego-driven design because of a misunderstanding of the causal link between Steve Job’s character and behaviours and the look and success of Apple products?

Some good quotes from Chapter 6 “Design is for people” from John Edson’s book Design Like Apple:

Apple assumes the role of the customer in the design process and considers every aspect about the product, from the user interface to the in-store retail experience when the customer finally comes into direct contact with the product.

Isn’t that empathy?

Apple applies that principles to technology, using design to add a distinctly human sensibility. It makes technology feel emotional, as if a friend rather than an infuriating automaton …

So now we’re entertaining the idea that the products we design can display empathy rather than necessarily being empathetic during design in order to build the right product?

It seemed that the insight and data that Jon and Chris talk about in the podcast is absent in Apple:

According to executives from Steve Jobs on down, Apple doesn’t operate like many other companies in that it doesn’t ask the market what to make or undertake conventional forms of research. Jobs distrusted research. Instead of asking customers or the market about products, Apple works largely from intuition and a pervasive human-centred ethos.

How can you claim to be human-centred and yet shun research into the needs, preferences, motivations, and goals of customers?

Instead of focusing on marketing research or feedback, Apple has established an internal process where design ideas are traded and filtered in the development process.

So basically “Designing for people like us” and not even bothering to practice empathy, although Jon and Chris point out that’s not necessarily a bad thing (and Apple’s success would support that):

As long as users are somewhat like you I think there’s a lot you can figure out just from your own thoughts and preferences about usability

But tweaking the details is different to choosing what to build in the first place. Apple can do what they like, they can (and likely will) fall on the sword of their own arrogance, especially now without a strong visionary leader at the helm.

Should we follow Apple’s example?

As designers who are entrusted by clients to get it right the first time we have a duty to do it by the book, play it safe, do the research and make evidence-based recommendations that maximise the likelihood that products and services we work on will be perceived by users and customers as useful, useful and hopefully even desirable.

Leave the big gambles to innovators like Apple where design direction comes from the top and the whole company is on-board with taking risks with big pay-offs. That’s generally not the space we play in.

What we call “ego”, Jobs called “craftsmanship”

steve jobs talking about what happens when the marketing/sales people take over from a ‘product’ founder is… eerie pic.twitter.com/LQgpaZ6OyU

You can be an amazing designer but utterly ineffective because you fail to elicit the support of your client and peers

The things you care about, your values and your priorities as a user experience designer will differ to those of the analyst, the tester, the project manager and even the client.

Sometimes your conclusions will be wrong but much of the time you’ll just have a different perspective on a problem based on your experience, your methodology, and what you focus on.

Where others are coming from a technical background and are thinking about the technology, capabilities, technical debt and lines of code you are thinking about how people will perceive and use something.

Where others are thinking conditions, constraints, organisational efficiency and resource management you are thinking about contexts of use, activities, and human factors.

Where others are thinking simplicity, ease of implementation, repeatability, and reusability you are thinking about the nuance of how to do it right so people will find it useful and usable.

Don’t let people convince you you’re crazy for being the only voice in the room speaking up for users, participants, consumers and citizens.

Don’t let people convince you that you’re overthinking what seems to them easy problems with obvious solutions because they’re not seeing through your lens. You might see complexity and challenges they don’t.

Don’t back down when people disagree with you just because you’re outnumbered. If you’re the expert on the topic or problem being discussed then it shouldn’t come down to a simple majority vote.

When you are overruled, don’t give up. If you made a good, solid argument and presented it articulately and passionately then you made progress. Your team or your client will have learned something new thanks to you.

Be smart, keep a cool head and continue to chip away, establishing credibility so next time they’ll listen longer and more intently … before shooting you down. It’ll likely happen a lot.

Don’t retreat into your cave and give up. See every chance to debate as a step forward. Seize opportunities to demonstrate what you know and are capable of.

Of course don’t expect to get your own way, ever. See yourself as an influencer, part of an equation. You represent one view and others represent equally important and valid views. Together as a multidisciplinary team you push and pull at problems and decisions and choose the best outcome that covers all bases.

Remember you don’t deserve respect, you have to earn it. Every time, with each new team, manager, and client.

This is what will make you an effective designer. Stubbornness with humility. Tenacity. Passion and enthusiasm. A willingness to understand not just what drives the people you design for, but the people you design with.

If you enjoyed this article please share it with your friends and colleagues.

Often designers are accused of or cautioned against adding “bells and whistles” to products, based on the premise that designers are like make-up artists or just put the icing on the cake.

Good designers work from the ground-up, from product vision and strategy through research and analysis to design tools for people that are perceived as usable and useful, even desirable.

There shouldn’t be so-called “bells and whistles” or superfluous features that cannot be demonstrated to have derived from requirements and objectives. There are just low- and high-value user stories, and low and high costs to implement them, and the product owner makes a decision about whether investing the time, effort and money into a low or high value feature, experience, streamlining or other change to a product is worth it.

To lump designs into a “bells and whistles” bucket shortcuts the conversation about whether an interpretation of a user story is valuable and worthwhile.

If you enjoyed this article please share it with your friends and colleagues.

Even if a user story requires zero effort to implement, it’s still important to apply the same principles of user-centred design and evaluate the suitability of a solution against an identified activity and goal.

Some features of commercial off-the-shelf (COTS) products have been in development for over a decade and are considered very mature. That doesn’t mean they’ll be considered usable and useful for your market. It probably means those features are very sophisticated, support many edge cases and have no defects.

From one angle those are all desirable attributes. From another angle those attributes can be detrimental. You’ll be tempted to just bolt them onto your product without assessing them against how people might perceive and use them. You’ll be less likely to put them through the same rigorous testing that your own code is subjected to. And being ‘fully-featured’ can actually interefere with what otherwise could be a straightforward activity with additional decision points and complexity at the user interface.

Take jQuery File Upload as an example:

As far as a file upload plugin goes, this has everything and the kitchen sink:

Browse to file on computer

Upload a file

Cancel or abort upload

Upload multiple files

Delete uploaded file

Delete several uploaded files

Select all files and delete them

Display size of files before uploading

Display and update upload speed in kilobits per second

Display and update upload timer in hours, minutes and seconds

Display and update progress indicator as a bar

Display and update progress indicator as percentage to two decimal places

Display and update progress bar as file size uploaded

Cancel all file upload activity

File names for selected and uploaded files

Upload a file independently of all selected files

Commence upload of a file independently of all selected files

Cancel/abort upload of a file independently of all selected files

Larger file sizes shown in MB instead of KB

That’s a lot of features! You couldn’t expect a bespoke software product to contain all those features and would be unlikely to write user stories that would result in all those attributes, unless multiple file upload was central to your application, as it is for Dropbox and Google Drive.

But for most websites and web apps I’ve been involved with that have a file upload component, the workflow is pretty simple. Typically a single file of a size small enough for such verbose progress details to be not just inappropriate but clutter.

Can we live with the button being labelled “Delete”? Does it make sense to have a bulk upload-capable plugin when the form being completed by the user only expects a single file? Are people going to figure out they need to close the dialog once they’ve finished by clicking the ‘x’ icon because there’s no ‘next’ or ‘done’ button? Will files ever be so large as to need an upload abort button?

The following diagram illustrates the difference between a solution-centric view of evaluating out-of-the-box (OOTB) features and a user- or problem-centric view.

The solution-centric view (left) would see user needs as a subset of the features provided by the ‘mature’ solution.

Where the solution-centric view sees bonus features and ‘value add’, the user-centric view sees avoidable complexity that increases the cognitive load on users for what should have been a simpler, less-featured and better-integrated solution that supports the activity, for example:

User comes to online form expecting to upload a file

User already has the file ready to upload

User selects the file from computer

User submits form, which uploads file

User walks away

Does not require a “file manager” idiom. Does not need to see files upload in realtime. Does not need to monitor upload. Does not need to review filenames and file sizes. Does not need to remove uploaded file. Does not need to abort a file upload operation. Does not need to think about uploading files as a sub-form of the main form that you enter into and then exit from to return to your main form.

The latter view can only be arrived at by following the same process as for the rest of your software and describing the tasks, objectives and situations of actual system users without presupposing a solution.

COTS products are often a great way to implement a solution cheaply and quickly, taking advantage of years of research and development by other companies. You never want to set out to replicate mature platforms and content management systems like Sharepoint, Drupal and WordPress. But have you ever tried to explain the ‘power’ of Web Parts to a content author and have them respond “But I just want to …”

Don’t fall into the trap of solution-centric thinking where more features equals more value. It’s often the opposite where poor integration with users’ mental models and workflow, additional buttons, form fields, screens and decision points actually decrease productivity and perceived usability of the solution.

If you can use an existing solution or plugin to satisfy a user story and any disrepancies or trade-offs are worth it (even if it means an increased abandonment rate or lower level of user satisfaction) then great, go for it.

Don’t be like Beni in The Mummy and load up your camel with gold treasures. It didn’t end well for him.

Stay focused on what you came for. Lead with your stories and work the problem space before moving into the solution space. Then and only then look to see what is available to use or co-opt, and assess its suitability against the story and acceptance criteria.

If you enjoyed this article please share it with your friends and colleagues.

The five levels are a model for how to assess and perceive software quality ranging from ‘functional’ at the lowest tier where the software is good enough to be deployed because it passes unit tests.

The top tier is occupied by the likes of iOS, Adobe Photoshop, Atlassian JIRA (though that one is up for debate), Buffer and Evernote; software that transcends being just useful to popular (and not in the way that Windows 10 is ‘popular’ because Microsoft is forcing it on everyone).

In his blog post Gojko makes a parallel with Maslow’s hierarchy, so ‘successful’ in this software quality pyramid roughly equivalates to ‘actualisation’. Software that is so good people love it.

But what if instead of a single scale that covers the entire product we look at evaluating parts of a product? This may be a bastardisation of the concept, but let’s just play with it for a second and see if this is useful.

Instead of an overall score of “Works well” or “Useful” let’s slice the pyramid vertically where each slice represents a feature, workflow or user task.

It’s not just a way of evaluating different aspects of software but also a way of thinking about intentionally having different quality criteria across your product.

Perhaps a basic ‘functional’ implementation, a single iteration of a feature may suffice for a feature used infrequently by a minority of your userbase.

Frequently-used features need to be highly refined with several iterations and higher quality criteria (no known defects, performance etc) to be deemed satisfactory and competitive by your target market so they would need to attain at least ‘usable’ status.

I’ve overheard conversations between agile development teams and product owners to pare back test scripts because the high level of quality agreed on was overkill for some user stories.

What if instead of getting into the minutiae of which test scripts to suspend for a user story the team could instead ask:

Does this feature need to work well?

How often are people going to need it?

What sort of people are going to want to use it?

Is it just a shortcut or accelerator for something that can already be done?

What do users stand to lose if it doesn’t work well?

What do we stand to lose if this feature doesn’t work well?

How much effort is involved in making this useful?

How much effort is involved in making it usable?

What might be the ROI if we work on this until it’s useful?

What might be the ROI if we settle for ‘works well’?

If we aim for basic ‘just passes unit testing’ might that detract from the overall experience? For whom?

So where does MVP fit into this?

I’ve avoided using the term ‘minimum viable product’ in this blog post and I want to point out why. When iteratively developing a product it is considered poor practice to think of it in terms of this pyramid where you build the entire product to a ‘functional and deployable’ state and work upwards.

First, that’s a poor way to determine whether your vision is actually going to result in a viable product from a market perspective.

Second, it often results in decisions to ship overly basic, uninspired and me-too software that meets internal criteria for MVP but actually falls flat in the marketplace.

A bottom-up approach like that is not agile, not adaptive, not open to learning and incorporating new information and assumes that the entire scope of what you envisaged from the start is both required and is best delivered in the way envisaged.

You’re likely to throw money away on features you could do without, money that would have higher ROI making other features usable, useful and contribute to a successful product.

When thinking about your MVP or Minimum Viable Experience you should slice the pyramid vertically. Pick one activity, one scenario, one user group and do that well. Test it with that smaller user group, learn from it and get a better feel for what might actually constitute a viable product:

There’s also this comparative diagram with different tier labels and slightly different intent to the quality pyramid presented above (author unknown):

If you enjoyed this article please share it with your friends and colleagues.