Digital product delivery and its impact on businesses, teams and people.

Category: UX (Page 2 of 2)

Feature trading to facilitate change.

Those who have worked with me will know that I can sometimes be as frustrating as hell! I work by a let’s get it done mentality; rules be dammed. Why, I wonder, follow the rules when the bureaucracy actively prevents humans acting reasonably to work together to bring a project to fruition. Trust in enlightened self interest I say!

The fear is, of course, that at some point another’s view or agenda will take precedence, diverting the project from it’s original goals. We spend weeks and months defining and tying down, the how’s to ensure that everyone knows what they are responsible for. These rules are ultimately designed to mitigate the financial risks of the organisations we work for.

There are real constraints though: a goal or vision must be defined and measurable, the outputs must be declared and the outcomes must be measured. Project plans, milestones and checks and balances exist to ensure the successful delivery of the project outputs. After all, we are ultimately constrained by time or money and usually both.

By measuring the project at the vision or goal level we are able to determine if a project has succeeded or failed, without having to legislating for every individual action. Conversely the act of legislation prevents creative thinking, and learning, from happening ensuring that efficiency and positive feature changes are not discovered.

By denying the activity of continual discovery we are unwittingly adhering to the fallacy that we can accurately predict future wants and needs. I.e. Future efficiencies and better functionality cannot be explored as the problem space is illuminated because they weren’t declared ahead of time.

Where change is recognised, the business case is presented and a change request is created. Usually though this is a one way street. Features are taken out while project expenditure remains the same and additions always increase the project expenditure. Reinforcing the need to restrict change as “scope creep” is always presented as having a negative impact on a project.

I therefore suggest creating an feature/output trading scheme. Whereby all change regardless of the impact is assessed this includes the financial impact; Good or bad. If the impact is positive (for the project) put the balance in the project bank, for when something goes wrong. If it’s negative and you have something to spend, spend what you have. If there is nothing in the bank to spend, you at least have the data you need to decide the next step.

For example

It is discovered that feature a/output b is no longer needed. An impact assessment is drawn up showing the impact of not doing it, including financial saving. If agreed, It’s withdrawn and the saving is added to the project balance. Later if feature c/output d is required, an impact assessment is drawn up showing the impact of doing it. If the change is agreed and there is a positive project balance the costs are transferred and the change is committed. If there isn’t a project balance a business case us drawn up and more fund requested with the data from the impact analysis used to support the request.

I’m in no doubt that this simple idea is unofficially in practice in most projects. Except, that when something goes wrong and you need to understand who’s financial responsibility it is (I.e. Who’s to blame) the whole house of cards can comes tumbling down. As it is unofficial: Change, financial impact and trade offs are not captured and therefore the problem can not be measured against the original brief.

By acknowledging the reality of the situation in a transparent, documented approach we can embrace change, allow new discovery to flourish knowing that at a later date, as long as the bank account balances, everything is okay.

p.s. for any agile practitioners out there i know an agile approach can facilitate change as described above. Agile isn’t a pervasive methodology for most of the clients i work with.

Customers, customers, customers.

In the immortal words of the Scottish philosopher Billy Connolly “There is no such thing as bad weather, only the wrong clothes” and so it is with clients.

Let’s be honest, there are some businesses you should never work with and some who are slightly more work than others. Sadly, it’s this mismatch between agencies and clients that allows the “bad client” myth to prevail.

Clients you should never work with
Like people, there are some businesses you should never, ever work with. Do your homework; the engagement process is a two-way street. You can be certain they’ve checked you out thoroughly and you should do the same.

  • Do your company cultures fit? If you’re an agency that specialises in mobile website design for the games industry then don’t commit to creating a corporate intranet. Say NO.
  • What’s their burn-through rate? If they are burning through a couple of agencies a year, something’s broken and you probably won’t be able to fix it. Say NO.
  • Do you have to cut your prices just to get in the front door? You have overheads so what’s the use in going out of business before the job’s done? Say NO.
  • Are you being asked for the moon on a stick? You’ll never achieve the impossible, so if they aren’t prepared to be realistic say NO.

I know it’s tough to say no. You’re worried where the next cheque is coming from and there’s rent to cough up and staff to pay. But if you say yes you’re going to hate it. Worse than that, you’re going to demotivate your staff and you could miss the opportunity that’s just right for you coming around the corner.


Clients that are more work than others
If there is nothing fundamentally wrong but you find yourself being knocked from pillar to post then it’s time to take control. You’re the experts, you’ve been asked to deliver a project and that’s what you’re going to do.

Four simple tips:

  1. Be honest – explain the difficulties and propose a way of working to ensure a successful outcome.
  2. Communicate – Let your client know what’s happening. You don’t have to respond immediately but don’t neglect them. Most problems can be resolved quickly with a simple phone call.
  3. Set realistic expectations – Do not over promise and under deliver.
  4. Set ground rules – How will changes be factored in? What response time will you provide on emails and phone calls?

It’s probably not going to be smooth sailing, and you’ll probably have to reiterate the rules several times, but in the end you’ll find a happy medium that works for both you and your client.


Daniel Kahneman: The riddle of experience vs. memory [and its implication for user experience]

Pointed out by @sparklypips – A fascinating video on the memory of events.

Daniel Kahneman gives an insightful TED talk on the science of happiness and the role “the experiencing self” and the “remembering self” plays in our perception of events.

The huge implication for designing the user experience is capture in the (rather grim) colonoscopy story which describes the experience of Patient A and Patient B.

Patient B experienced more pain throughout the procedure but when they were both asked to remember the event later Patient A remembered a worse experience. This was because the pain Patient A remembered at the end of the procedure dwarfed the relatively “good” experience they had throughout the rest of the procedure.

In terms of UX design, it shows a good user experience can be entirely undone if the exit point (or offline process) is inconsistent with a good online experience.

Beginners, Experts and Perpetual Intermediates – User Typology

In Twitter usability: Is it really a problem? I argued that the “usability” issues experienced by novice users aren’t worth worrying about as user is only a beginner for a fleeting period of time.

I’d like to expand on that slightly as the concept of designing for Beginners, Expert and Intermediate users. This topic preoccupies most people who design interactive systems, Who are our target audience? What are their competencies?, and if we don’t understand the nature of the users over the long term we are liable to design in problems without even realising it.

As Alan Cooper writes in both About Face and The Inmates are Running the Asylum it’s the Perpetual Intermediate who you want to keep in mind.

The experience level of people performing and activity tends, like most population distributions, to follow the classic statistical bell curve. For almost any activity requiring knowledge or skill, if we graph number of people against skill level, a relatively small number of beginners are on the left side, a few experts are on the right and the majority – intermediate users — are in the centre.

He goes on to say

Statistics don’t tell the whole story, however… the beginners do not remain beginners for very long. The difficulty of maintaing a high level of expertise also means that experts come and go rapidly, but beginners change even more rapidly.

The occupants of the beginner end of the curve will either migrate into the centre bulge of intermediates, or they will drop off the graph altogether and find some product or activity in which they can migrate to intermediacy.

If this is true then a good user interface must enable beginners to make a smooth transition into intermediacy. It must enable them to quickly understand the features and scope of the application while not restricting the expert user, who demand faster access to functionality they use most in their work. However, a really good user interface must dedicate most of its efforts to meetings the need and objectives of the perpetual intermediates.

As cooper says

Perpetual intermediates need access to tools. They don’t need scope and purpose explained to them because they already know these things [ED: they learn that in the beginners stage]. Perpetual intermediates will be establishing the functions that they use with regularity and those that they only use rarely. The user will demand that the tools in their working set are place front and centre in the UI, easy to find and easy to remember.

If you’re interested in find out more about this, I’d strongly recommend reading The inmates are Running the Asylum by Alan Cooper for a good UX orientated view. If you want in a more technical book then read About Face 3: The essentials of interaction design also by Alan Cooper  (they both cover pretty much the same ground with About Face going into slightly more technical detail).

Twitter usability – is it really a problem?

An interesting essay entitled “Experiment: Twitter Usability – A new users first experience” has been bubbling up on my twitter timeline today. It raises some interesting usability issues on twitter, particularly regarding new users.

On face value, these could be a problem but they aren’t and let me tell you why.

Firstly, the “new user” phase of someone’s engagement with twitter is fleeting. You are only a new user for the time it takes you to:

  • Sign up
  • Post a tweet
  • Follow someone for the first time.

From then on out you are a user. You want to keep up to date with your friends, let people know what your up to and to start building up your network.

Over time and through accretion you become an expert user. You learn to optimise your typing style to adapt to the restrictive 140 character limit, you use a shorthand vocabulary that would make doctors seem as if they are speaking in plain English.

Twitter understands this and that’s why the site is designed to support users and expert users. Sure, they could make the sign up for a little easier but you’ll only fill that in once. You will, however, use the update control, and timeline as your primary view of the twitter platform constantly from then on out. Which is why they are the most prominent features of the site and easy to learn.

Here’s the rub – twitter is a messaging platform, one which most people engage with through other tools. A quick scan down my timeline shows that no one is using the website to post messages. They are using: Tweet Deck, Tweetie, HTC Peep and countless other clients. So the “clunky” nature of the website is irrelevant to most users of the twitter platform.

SEO and User Experience – The case for a unified strategy

Things seem to happen in three’s – I’m not sure why that is, perhaps it’s a universal truth which underpins the universe. However, In the last week, I’ve been asked three times what’s more important SEO or User Experience. My answer?

User Experience and SEO should be a unified strategy. 

The one thing everyone can agree on is that in a very short period of time SEO has become an integrated business function. The board-level executives get it. Essentially this is because ROI argument is simpler.

If we spend x amount on SEO and can see a y% increase in the number of site visitors.

Then all you have to do is rely on the funnel effect which will ensure there is an increase in sales.

Relying on the funnel effect as a sound business strategy is debatable but the truth is It’s not their fault. After all, this is how most previous marketing approaches have been applied. Direct marketing, TV advertising all work on the same premise. Show your product to enough people and some of them will buy it. The problem is that this model doesn’t work so well on the web. If a customer gets frustrated then they are just one click away from your competitor.

This is where User Experience comes in. A User Experience strategy will enable a business to measure the site’s performance against its business goals and user needs. It gives business customer insight to enable them to strategically target areas for improved design and development to ensure that a visitor is turned in to a customer,  maximising your SEO spend to generate more profit.

Your user experience strategy will be individual, so where is the best place to start?

You must always start with a clear goal. This will enable you to determine the best activities to undertake to establish how you’re going to achieve it.

For example

A business may have the goal to increase the profitability of their online store.

I ask myself several questions:

  • What’s happening now? (The good, the bad and the ugly)
  • What needs to change to achieve the goal?

To understand what’s happening now evaluate the business intelligence to find out why we’re not already achieving the goal. Most companies have a wealth of information already available such as Customer feedback, Analytics etc. which will point towards the problems.

Other activities to generate usable data could be:

  • Heuristic evaluation – to asses the overall usability
  • Competitor analysis – to see if anyone in your market segment is doing better (or worse)
  • User testing – to see how people currently understand your product or service.

If you see that the product categorisation is confusing people you know to do a card sort to produce better categorisation. Making it easier for customer to find the product they want to buy.

If you determine that most people don’t make it through you checkout process you know to target your dev budget at creating a new one. In addition you might create personas to aid the design and development process to keep the customer in mind throughout. Then you might also run some user testing in the design phase to ensure your heading in the right direction before it’s too late.

In addition to the increase in the bottom line the tacit advantages to a good user experience are:

  • Engagement
  • Customer satisfaction
  • Loyalty to brand / Building champions
  • Awareness
  • Ethics

Not only will you earn more, but you’ll also create a warm fuzzy feeling in your customer too, who will want to come back again and again. Just ask Amazon about this.

Essentially SEO and UX are not competing but as part of a unified strategy will significantly increase your product/services visibility and turn more browsers into buyers.

XHTML – Most common page validation errors and what they mean.

Quite often I’m asked to review a client’s website for accessibility. One of the first things I always do despite the desired conformity level is to validate the (X)HTML (validation is a prerequisite of “aa” conformance).

Here are the most common error’s I come across when validating to XHTML.

  • Elements and attributes in upper case. All element names, attributes name and values should be in lower case to meet XHTML specification.
  • Missing attributes. XHTML requires certain attributes to be specified. Such as type on script tags.
  • Depreciated elements/attributes specified. XHTML has a smaller subset of HTML attributes due to the separation of presentation syntax to style sheets. All height, margins and other style-related values should be moved to the style sheet.
  • Closing tags: All tags should be close to ensure validation. Inline tags such as img and br should always be self-closed. Ie. <br /> and <img /> As this will case further validation issues down the document tree as the browser miss-interoperates future closing tags.


It’s important to ensure that your page meets it’s declared doctype as some errors prevent the page rendering correctly which then impacts the accessibility of the site and may in some cases prevent the site from rendering at all.

Other than the accessibility considerations, a page that doesn’t validate indicates to me that a developer/designer isn’t aware enough of the implications of the code they are writing, typically the page was created in a rush and I’m less likely to see any of the more advanced approaches to accessibility, I would consider essential for a good user experience.

Caveat – In some instance, a page can be invalid but still accessible. It used to be that .net added attributes to its generated HTML willy nilly. As I say this is an indicator to do some more in-depth analysis.

The dark side of prototyping

Going high-fidelity early in the design process

The term fidelity means how perfect a prototype is made (if you want to read more on this subject, you might want to read my article Balancing fidelity). As with perfection in any other area, perfection in prototyping comes at a cost:

It makes the design process rigid. Obviously, creating and making changes to a high-fidelity prototype takes more effort than to a less perfected prototype. It’s a labour-intensive approach and doesn’t lend itself to a creative and dynamic design process where we want to explore alternatives and be able to quickly change things that don’t work out as expected.

We get attached to our creations. We all hate making changes to things that has taken us a lot of effort to create. Since high-fidelity prototypes take blood, sweat, and tears to build, we are more likely to become reluctant to improve them. We get attached to our initial ideas and will settle for less than good enough. Also, managers are likely to be highly reluctant to support costly changes to something that has already taken its bite of the budget.

We waste time on things that will be changed anyway. Prototypes are built to get answers to questions that are important to the product design. The longer it takes us to create the prototype, the later we will get the answers we need. And the more time we use polishing our prototype, the more time we risk wasting on something that won’t survive the next iteration.

We will have to struggle to get the feedback we need. If we present a detailed prototype to our clients, their eyes and attention will inevitable be drawn to the details. Issues, such as colours, image quality, logo treatment, typography, spelling, data validity, stability, and response time will put the conceptual aspects of interaction design and of information architecture in the shade. Form will trump function, and minor flaws and temporary solutions will stand out. While the details have to be discussed sooner or later, it’s counterproductive if the design is still in a conceptual stage. We will get a whole lot of input, but will have to struggle to get feedback we need.

Usually, i love the articles at GUUUI but i don’t agree with this post.

One of the big drawback of low-fi prototypes is that we have to ask a lot from our customers to envisage the proposed idea.

Quite apart from tools like Axure. A wealth of CSS and JavaScript frameworks exist to speed up this process. (Blueprint and jQuery are my personal favs). Plus we get the distinct advantage of creating a prototype which can be tested with real users earlier in the design/development life cycle.

With some planning, these can be easily changed to support future development so the cost of development isn’t wasted. Let’s not pretend that the prototype won’t be re-used. (Build one to throw away is one of the biggest fallacies of the software development process)

Sure you have to remind clients the design isn’t finished or that it’s not pulling real data from the database but in my experience, that’s more than made up by the client getting the idea being proposed.

What is usability anyway

With 57% of the UK population having access to the Internet now has never been a better time to launch a digital product, but research also shows that users have become more impatient. It now takes only 4 seconds for a customer to make a decision about the companies they encounter on the web, and whether they will use their products or services or go elsewhere.

With this in mind, it’s never been more important for a company to create a product that meets their customer’s expectations. It is essential to create an online experience that will engage the customer so that they feel as quickly as possible that the company not only has the item they want, but they are able to provide it in a way that is quick and simple.

Traditionally, these challenges have been met technically by software developers, websites have become more complex, and through the advancement of web 2.0 technologies there is very little to distinguish between a traditional software application and a website. Alongside the rise of technology and the Internet, a legion of usability engineers have been quietly working to shape the web to become more usable; more inline with customer’s expectations.

We all experience the efforts of these usability engineers but the truth is that most people still don’t know what usability actually means and what measurable benefit it will bring to a company.

What is usability?

“Usability is an approach to product development that incorporates direct user feedback throughout the development cycle in order to reduce costs and create products and tools that meet user needs” – What is usability (Usability Professionals Association)

In short, a usability engineer works with product developers to test how easy it is for someone to use their product. This is done many different ways but the most common are:

User testing – a usability engineer will watch people use something and make recommendations on how to improve it to give better results for the user.

Expert review – a usability engineer will review a product and make recommendations on how to improve it to giver better results for the user.

Make sense? Usability touches every part of your life; think about it tonight when you drive home, get through your front door to uncork a bottle of your favourite Chardonnay and relax while listening to your favourite music. The fact that you drove home in comfort and safety, that you got into your house, that you uncorked a bottle of wine, that you can literally listen to thousands of your favourite pieces of music on your MP3 player without even thinking about it, is testament to how much usability touches your life.

Across a study of 863 projects it’s been estimated that you can benefit from a measurable increase of 135% by setting aside 10% of your development budget for usability , as well as other benefits such as an increased in brand loyalty and word of mouth marketing.

Products have come a long way over the past 30 years, but there is still much to do. One area of usability that needs to greatly improve is accessibility; from 1st October 1999 it became a legal requirement that “a service provider had to take reasonable steps to change a practice which makes it unreasonably difficult for disabled people to make use of its services”.

What is accessibility?

Accessibility is the term that describes a field of usability that aims to explicitly improve the usability of a product for people with disabilities such as visual impairment, dyslexia, hearing impairment, mobility problems etc.

It’s no longer acceptable for a company to create a product without providing equal access to everyone. Moreover it’s really bad business!! I can’t think of any company that wouldn’t want some of the £50bn that the 8.6 million registered disabled citizens of the United Kingdom have to spend – or the £175 billion the UK’s over-50’s have to splash out (most people over 50 have some form of impairment such as deterioration of their sight).

The secret here is that accessibility isn’t expensive either, as long as it’s designed into your website from the start. A few simple techniques, can give you access to a combined market of 225 billion pounds, and if that isn’t good enough…those same simple techniques will make it piece of cake for Google to find and rank your website because Google accesses your website in the same was a visually impaired user with a screen reader does. Optimise for accessibility and your search engine ranking is likely to improve.

User experience in the software development team

User Experience (UX) design is traditionally seen as the domain of user interface (UI) design, but within a software development team it should mean so much more! UX should permeate through the whole development team. It should influence the way middle tier developers’ craft their components and the way database administrators create their tables, stored procedures and views.

Update: This article has now been published in UsabilityNews

Within a software development team, most talk of creating a good “User Experience” usually relates to creating an intuitive user interface. In the traditional sense this means;

  • The layout of the buttons,
  • The ability for the application to remember contextual information,
  • Or the intuitive nature of a web site navigation system,

but these interfaces, although important as the “face” of the application, are actually only a small part of what makes up the product.

Beyond the User Interface

A software application, like an iceberg, has a great deal of it’s complexity in the underlying structure of the program, the object model, where there are countless different members (interfaces, methods, and properties, delegates etc.) which transfer and transform data between objects and to and from the database.

While not as visible or as glamorous as the UI these are all interfaces that have users, your colleagues, whose needs must be satisfied.

On one level these “users” could be considered the most important users to satisfy because the culmination of their efforts make up the finished application, the ability for them to produce good software and the trade-offs they make in order to create the software will have a big influence on it’s character.

With this in mind the environment and the mind-set a developer works in is crucial to their ability to produce a good overall user experience. Every effort should be taken to ensure that they are focused on creating a good quality product, not in compensating for an awkward development environment or in acquiring the contextual information, from obscure code, that they need to complete their task.

Creating the right environment for UX to flourish

Every developer should be encouraged to develop this mindset; one way is to ensure that you create code that enables your colleagues to interface with it easily.

The simplest and most effective way of doing this is by naming your classes and members appropriately.

As a rough guide;

  • Your objects should be named clearly.
  • Your objects and their members should be named so that their intention is obvious.
  • Your members should exist harmoniously within scope of the class they inhabit, as well as the overall application.

When the ambiguity is taken out of the development activity, the amount of tacit knowledge needed to complete a task is diminished and the communication between team members is simplified but it’s in the subsequent phases of the project when this clarity pays real dividends. Creating an object model that is clear and expressive reduce the amount of background information that has to be re-learnt and understood before starting a development task, allowing the developer to become productive quicker.

I intend to discuss this topic further, the theme that every opportunity should be taken to reinforce a user centric mind set is, I believe, critical to the development of good products. Only by cementing the “user” in all it’s forms as an integral part of the development process will the team truly understand what is needed to create a successful User Experience.

Newer posts »

© 2021 Matt Goddard

Theme by Anders NorénUp ↑