Instead of putting the blame on users and leaving it at that, there are times when it is more sensible and worthwhile to invest in finding the issues our users are facing and uncover root causes of their frustrations. Usability testing to the rescue.

If you ask any UX professional out there on what they think about usability testing, I’m guessing everyone will say stuff along the lines of – Awesome, Absolutely critical, Important, The Qualitative Input we got was priceless.

It’s a great idea, and the sad part is when it stays as an idea, and not part of the product development processes. As a realist, I’m a believer that every piece of investment must be justified and make economical sense, that includes usability testing.

So how do we get buy-in to have it introduced?

Usability Testing? What’s that?

Rather than reinventing the wheel, this is what wikipedia says:

“Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users.”

That sums it up pretty well.

The Purpose

Before delving into means on getting buy-in to do usability testing, lets first look at the purpose of doing usability testing:

1. Uncovering usability issues and missed expectations – Users might be confused on how to reach their goal, not knowing how to go to the next step, or features they assume would be included are not there.
2. Stop and learn – From the lean startup approach, rather than churning our feature after feature, there are times when it makes more sense (even from a monetary standpoint), to stop and learn, before deciding where to invest next.
3. Informing decisions – Uncovered issues can assist in informing the feature prioritisation.
4. Finding the root cause to problems, rather than symptoms – So rather than investing significant development effort on fixing symptoms here and there, finding root causes make fixing it now possible.
5. Clarifying ROI – Providing a measure on whether or not a feature is successful in enabling its users reach their goals effectively.

Getting buy-in to do usability testing

In a nutshell, justifying to get started on doing usability testing would require:

1. The right situation or crisis
2. Figures on the return on investment it will deliver
3. Quick wins

The right situation, or crisis, is crucial

It hugely depends on the situation of your team or company is in.

Why do I say so? Well, getting buy-in to put usability testing in place is almost impossible in the following situations:

1. Stakeholder and product owners have absolute confidence that their product delivers exactly what users want.
2. Stakeholder and product owners have absolute confidence on the designed solution for new features or enhancements.
3. Customer support is cruising.
4. The product is making a lot of money.
5. There are no customers dropping out.

That sounds like utopia to me. But when if it all goes wrong? Usability testing to the rescue!

Its only in situations or crisis like these, which usually happens pretty often (And thankfully keeps us UX professionals employed), the value of usability testing is realised. I’ll briefly go through the value against each of the outlined scenarios.

1. Stakeholder and product owners are uncertain that their product delivers what users want – Usability testing can provide insights into whether users are able to reach their goals efficiently and uncover usability issues and missed expectations.
2. Stakeholder and product owners are uncertain over the solution their design team have came up with for new features or enhancements – Usability testing can be done on the designed solution to see if it works with users or not, there are times when its even worthwhile to test multiple solutions against users, to get some qualitative information to inform decisions moving forward.
3. Customer support is knee deep in support requests – Rather than fixing problems based on support tickets, which could be just symptoms of a bigger problem, usability testing can at times help uncover root causes to problems. So the next time you hear users say “This feature is not working”, it might be time to stop and observe how they are using the feature, just like in the video above.
4. The product is not making money – Usability testing would only work if the problem is due to usability issues and missed expectations, where it can help uproot them. But if its other problems then sorry bro, usability testing ain’t the way to go.
5. There are customers dropping out – Similar to #4, if customers are dropping out due to usability issues and missed expectations, then yeah, usability testing can help get to the root of things.

Don’t forget ROI

As part of justifying for usability testing, some figures on the return on investment it will deliver is key.

It can be related to the situation you’re in, for example:

1. Dropout rates for an online purchase process are significant – Doing usability testing can uncover usability issues or missed expectations in the online purchase experience and inform decision making to smoothen the process and increase conversion rates.
2. Customer support are always receiving a large number of support tickets on features from a module – Doing usability testing can uproot key issues in the module, and hopefully inform decisions to fix it, which could in turn reduce the support tickets that are raised, and also reducing the time customer support staff need to spend.
3. The design team came up with two solutions to a problem but are uncertain which one is better – By doing usability testing on both solutions with users, maybe with clickable prototypes, the design team are able to get qualitative information on which solution is better, which can then inform product decisions and give more confidence to the product owner and stakeholders that they’re investing in building the right solution.

Notice that the examples above constantly leads back to the money side of things. Not only is it crucial, its most likely the deciding factor.

Quick wins

If your company hasn’t invested in such activities before, do it only when you’re absolutely confident that it will be successful. If possible, focus on aspects that will provide the most impact in terms of revenue.

Blow it up the first time and it might be hard for there to ever be a second chance.

Finally

Do note that this is not a one-size fit all means of getting buy-in to introduce user testing, so please don’t haunt me if it doesn’t work in your context.

Being negative and all, the possibility of failing is always there, but remember that for every battle fought, the important part is learning from it and levelling up from the experience.

Drop a comment and lets to discuss how you are justifying for usability testing in your company and how is it working out for you, I’m more than interested to hear and learn from you.

It’s a programming term, so i’m pretty sure its hard to explain to non-technical audiences like my mom, so instead of trying your best to define and give example of how systems are coupled or not… think of it like the construction of towers.

Understanding the problems due to coupling
Imagine you are the architect you have built this amazing building with two towers and a connecting bridge in between.

And then you get a request that the client wants another floor to be added in between floor 20 and 21, calling it floor 20A, in Tower 1. And no you are not allowed to rename your floors because they want a brand-spanking new floor.

Which leaves you with a few choices:

1. Add another floor in between 20 and 21, but that will mean Tower 1 will be taller than Tower 2, and the bridge connecting both towers will need to be tweaked to connect again.
2. Reject the request and risk getting pwned.

Sounds like fun. But in the software world, thats a pretty minor case of issues due to coupling between systems.
Tight coupling, where it gets tricky
But in a world where some pieces of software are as integrated as ever, when it is designed to be tightly coupled, what does it mean?

Imagine you are the architect and you have the twin towers already built, but the difference here is that we have a lot of connecting bridges between the two towers.

And then you get the same request that the client wants another floor to be added in between floor 20 and 21, calling it floor 20A, in Tower 1. And no you are not allowed to rename your floors because they want a brand-spanking new floor.

Which leaves you with a few choices:

1. Add another floor in between 20 and 21, but that will mean Tower 1 will be taller than Tower 2, and a lot of the bridges connecting both towers will need to be tweaked to connect again, making it really risky. There might also be cases where we need to make changes to Tower 2 to support this change in Tower 1.
2. Reject the request and risk getting pwned.

Notice that the tight coupling between the towers have made adding the same set of enhancements more tricky, as part of the work will also include trying to build it in the way that doesn’t destroy the other bridges between both towers, which compared to the first set of towers with only one bridge, making changes to this set of towers would most likely involve:

• Higher risk
• Higher effort
• Higher investment

Why on earth do we need systems to be coupled?
When there is need to communicate between systems, there is need to be coupled.

You might say we should never build tightly coupled systems! But in the reality there are pros and cons across both, that someone as lowly gifted in technical architectural stuff like me would not be able to answer.

What does coupling have to do with UX?
A little, because the key pillar in UX is value, which I like to weigh as:

• Value to the user
• Value to the business.

So in both cases, users would be able to get value from it. But what about your business? There is a difference between investment for both cases, where for the tightly coupled case both investment and risk is significantly higher, due to a bigger scope of work, so from a ROI perspective there might be cases where it is worthwhile to say no to the client shove it aside.

In conclusion
Thank God that in the real world we don’t usually add floors to buildings that have been built already.

Thus when deciding between adding features to a system or not, remember that coupling is a huge factor in deciding how much investment and risk will be necessary, and weighing it alongside the value you as a business would gain.

Lets take a step back and imagine…you were just a small kid, and your dad brought you to this amazing Lego shop. And you, being that crazy Lego fanatic would just beg and beg your dad to let you buy some Lego.

Dad then went on to say: “Sure thing kiddo, I’ll let you pick any Lego sets.”

Your eyes widen in anticipation.

“But remember you only have $100 to spend on toys this year, not a penny more.”

Ok that’s not fun. $100 is a lot of money to a small kid, one things for sure it’s not enough to buy every Lego set in the store. What you would most likely do next is stress yourself out, think long and hard on which Lego set should you pick, is it worth the investment, will it be fun to play for the whole year, and go crazy.

That’s a tough call

Tough. Exactly the situation we face everyday in software projects, you would like to build everything but with project realities like budgeting constraints, resourcing, skills, technological limitations, release milestones and more….it’s basically impossible.

Deciding on what to build is tricky, prioritising that backlog on what features to build first is equally as bad, so rather than sitting back and admitting defeat, what could we do?
 

Starting with the Minimum User Journey

Rather than aiming for everything and impossibility, it is key to recognise it is much more important to aim for the delivery of features that allow for a user to meet his or her goals in using the system.

Build one of these features and a target set of users can achieve a goal, build more of these and more users can achieve their goal. With this approach, notice that you’ll progressively be able to fulfil the needs of more and more users as more and more time is invested in building these features.

Compared to what I like to call the “Big Bang” approach where we want to build everything in this list, regardless of the order, and just get on cracking…progressively building chunks of features would bring us the benefits of:

• Releasable code earlier in your project phase – You might argue that the product is not market ready without some features, but with even one journey in place, your product is ready to fulfil a user’s goal, hence making it possible to release. Whether it is sell-able or not is a separate matter entirely.
• Users can meet their goals – This approach is focused on making sure each delivery would allow one or more user goals to be achieved, hence there would not be any stop gaps in the end, unlike a “Big Bang” approach where stuff might be missed out, making a whole set of features that are dependant on other features being wasted.
• Spreading of testing load – Some tests can only be done when a full user journey is in place, so rather than having the testing team becoming bottlenecks when a huge chunk of features are built, having progressive deliver of features with one or more user goals can help in better spreading the testing load throughout your product development cycle.
• Prioritisation & ROI – Forcing the tough prioritisation decision even at day one will ensure better ROI throughout the whole project lifecycle, rather than chaotic tactical mess at the end of the project with with “Big Bang” approach, where the focus would be on averting the disaster than on ROI.

Sounds sweet, so how do we get started?

Start with some reading

Here’s a list of stuff you are recommended to first read, to get you better equipped in taking on the challenge of building the minimum user journey:

Other than these articles, it is also paramount to understand your product’s:

• Strategy – It’s paramount to understand your product’s mission, vision and milestones to ensure everyone is aligned and clear of the ultimate goal. If you don’t have one, its time to get one sorted.
• Users – It’s super important to understand the users you’re targeting, what are their roles? What are their goals in using the system? What is the environment or context they are in and more. This is where personas really come in handy

What is the minimum user journey?

That’s really subjective. With the information from the articles above, you’re pretty much ready to discuss and brainstorm on what are the features you need to build in the minimum user journey.

Some basic guidelines:

1. Each user journey must be tied to at least one user.
2. Ensure the user journey that is delivered it aligns to your product strategy.
3. Build only “Must-have” features. If you’re not sure whether the feature is needed, the answer is clear, it is not, de-scope it.
4. Use the Kano Model to segment what features are basic expectations, performance payoffs and excitement generators. You’ll be most likely building basic expectations only for the minimum user journey.
5. Rather than having opinion based arguments, always ask yourselves, what would the user need. Not what would the user want.

Summary

This article wouldn’t turn you from zero to hero, but I hope it gives you a clearer picture now on the importance and value for building for the minimum user journey.

Of course it would not end there, as once you have the minimum user journeys in place, the next bit will be to look what features to prioritise next. I’d highly recommend using the Kano Model to help facilitate that. If you would like to read more on how to build minimum viable products, check out this book on “Mobile First Design”, which gives a solid approach on deciding what to build and why, or check out the Lean Startup on building minimum viable products.

As for spending that $100, I’d go for Lego Spongebob sets as they are way awesome.

Photo courtesy of flickr user tasuki

Traffic lights are ubiquitous and can be found in almost any city in the world. Whether it’s a pedestrian crossing, road intersection or anywhere with competing flows in traffic, you will always see traffic lights.

The concept is simple:

Traffic lights alternate the right of way accorded to road users by displaying lights of a standard color (red, yellow/amber, and green) following a universal color code (and a precise sequence to enable comprehension by those who are color blind).

• Illumination of the green light allows traffic to proceed in the direction denoted,
• Illumination of the yellow light denoting, if safe to do so, prepare to stop short of the intersection, and
• Illumination of the red signal prohibits any traffic from proceeding.

http://en.wikipedia.org/wiki/Traffic_light

When it comes to designing software experiences this days, there is sometimes the need to display statuses against a record, usually coming in the form of a contrasting colour, self-explanatory icons, or even accompanied by text to better explain the status of the record.

Rather than re-inventing the wheel each time, why not look to the excellent design of traffic lights as a guiding principle?

Traffic lights are a part of life

Think about it, being able to understand how traffic lights work and what each colour means is something we all know. Red means “Stop”, yellow means “Look”, green means “Go”. It is ingrained in most of us since childhood.

Even without thinking, most of us react once we see this colours on our computer screen in our every day lives.

When to use it?

Just because some of the other systems uses statuses wouldn’t mean its suitable for your feature/context/product. Instead, its merely a solution that might come in handy in the following situation:

• The user is dealing with a big amount of records in a single go – Lists, Grids, Tables, etc
• There is a need to quickly communicate to the user whether they should be worried or not for some of the records.
• There is more than one information to communicate against a record
• There is limited screen real space

Interpreting statuses

I’m a big fan of the use of traffic light colours to quicken communication to users. On top of these 3 colours, I’m also very much into using grey as well. There are times when it would also make perfect sense to go the extra mile and use icons alongside statuses to communicate more information.

The tough bit is understanding that the communicated info would differs based on the context or objective of the system. Some examples below along with explanation on what it would communicate to the user and why is it necessary:

Inventory Management System

Status is used to communicate of stock levels.

Financial Solutions

Status is used to communicate of your financial situation.

Customer Relationship Management

Status is used to communicate a customer’s relationship with your business

Chatting Systems

Status is used to communicate which of your contacts are available for chat

Some real world examples

Examples of them being used

#	Example	Image	What does each status communicate?
1	Google Talk Chatting tool		Red for contacts that are online but busy, don’t disturb Orange for contacts that are online but away, might not respond Green for contacts that are online Grey for contacts that are offline Camera icon for people that have webcams Circle icon for people that don’t have webcams
2	Facebook Chat Chatting tool		Green for contacts that are online in their computer web browser Mobile icon for contacts that are online on mobile devices No icon for contacts that are offline
3	iconnect360 Membership management solution		Green for members that are active without any problems Red for members that have billing issues and need to be actioned Yellow for members that are suspended. Grey for members that are expired.
4	TortoiseSVN Source control software		Green for files that are same with the server Red for files that are modified.

Some tips and tricks

Below are some tips and tricks to take note of when showing a status of a record:

• If possible, minimise the use of colours between 2-4. Every additional colour would increase your user’s learning curve in using features.
• If your status is displayed as an icon, try to make sure the icon makes sense to the user.
• It’s perfectly fine to accompany each status with a short text, as long as it short and makes sense to the user.
• Less is more only if it is self-explanatory, so don’t cut that line of text and show an icon that nobody understands.
• There are situations when more information needs to be displayed to provide reasoning on why a record is now in a particular status, either:
  • Use a tooltip – Show the information only when the user’s mouse cursor hovers over the status
  • Use progressive disclosure – Hide it and show it only when the user clicks on the status a link beside it.
  • Show it – Have it alongside the status, maybe even in a list if there are multiple entries.

Summary

Just to recap, the design of statuses is just one of the many ways we can use existing design principles around us to shape interactions in our products, the key takeaway here is to make sure all statuses are self-explanatory.

Feel free to share in the comments if you find these guidelines to be useful.

Having recently collaborated with Microsoft in accelerating Windows 8 App development, I’ve came up with these design templates to serve as reference in designing Windows 8 Apps, providing more clarity in how to convert a conceptualised design from a Photoshop file into a full-fledged Windows 8 Apps with the use of Blend for Visual Studio.

Download link and more information on these design templates after the break.

What will you need to use this design template?

• Photoshop will be needed for the .psd files
• Blend for Visual Studio will be needed for the Metro Style App Project

What is in this design template?

Do note that this is a design template that only contains:

• Photoshop Source (.psd)
• Images (.png)
• Blend Project – HTML/CSS

Which means it does not contain any back-end coding, snazzy javascripting, complex business logic or more.

Mall App

(http://code.msdn.microsoft.com/windowsapps/Metro-Design-Template-Mall-7eec5358)

Introduction

I’ve always felt Metro apps would be a perfect fit for touchscreen based shopping centre directories, hence I’m coming up with a sample design template of a Mall app that will work like a kiosk, allowing shoppers to have a quick means to search, browse and find the information they want on the shops available.

Story

As a customer at a mall, I want a directory app that will allow me to search, browse and provide information on stores I’m interested in.

Movie App

(http://code.msdn.microsoft.com/windowsapps/Metro-Design-Template-0d0f39f7)

Introduction

As a big movie fan and cinema freak, I’ve always wanted a quick app that will allow me to browse the top movies in the box office, check out trailers, ratings and more. So when I was thinking of what kind of Metro Style Apps to create design templates for, I guess it was a natural choice to create a simplistic app to fulfill my movie craving needs, and hopefully yours as well.

Story

As a Windows 8 user, I want a quick and simple means to watch trailers of latest movies, check their ratings, and share it with my social network.

Reader App

(http://code.msdn.microsoft.com/windowsapps/Metro-Design-Template-d33d41a6)

Introduction

Having used many reader and aggregator services like Google Reader, pageflakes, Windows Live etc, I have always wanted a good feed reader app for my Windows Phone but until today I couldn’t find one. Even though Windows 8 already comes with a reader app, but its mainly used to read documents like .PDF and not really RSS feeds, so I’m creating this design template today to hopefully serve as a reference for you out there who is going to come up with a RSS Reader app for Windows 8 that i’ll definitely buy.

Story

As a Windows 8 user, I want a simple reader to allow me to read my feeds.

Feel free to use it as a reference or inspiration in crafting your very own Windows 8 Apps. Appreciate it if you can share in the comments if these design templates have been useful to you.

I like relating product features into…food. Think about your product as a restaurant, and the dishes you’re offering as your features. To add a new dish to the restaurant menu, you might even need to consider everything from what dishes to sell, the name of the dish, the recipe of each dishes, how to present the dish, what cutlery to provide along with that dish, how it will be displayed in the menu and more.

Tricky, which sounds exactly like how tricky feature decisions are in product development.

During the past few months, work has been piling up and with deadlines looming and project milestones in the horizon, it’s been a challenging period, forcing everyone around me to work not only faster, but smarter.

It has also pushing everyone into making more snap decisions, which are basically decisions that are done swiftly without too much careful thought, mostly based on experience or intuition. There are many that say that snap decisions aren’t such a good idea, but I’ve found them to be very effective at times, if practiced correctly.

But there are also cases where we’ll be stuck in endless debates on what should be built, how should things work, and it all gets trickier when differing opinions cannot be aligned.

Decisions need to be made

In an ideal world, all processes will work perfectly, there is always sufficient time to do effective research, balance them with business and stakeholder expectations, and come up with a technically awesome solution that meets everyone’s needs. Ideally this solution can also be easily developed, tested and released to customers on budget, on time.

In the real world, this is usually never the case, resourcing constraints, project realities (9 ladies won’t get you a baby in a month), scope creep, integration uncertainties, heightening customer expectations, misinterpreted requirements and many other issues usually mean there is usually not enough time for every project to be executed successfully.

Of course progressive effort will need to be done to gradually move towards a more effective project/product development lifecycle, but in order to get there, feature decisions will need to be made. In the software world, these decisions could be high level and just explain some scenarios or being detailed up to the level of deciding everything from captions, input control, workflow, behaviours, error messages and much more.

To make things worst, every single one of these feature decision will influence the final user experience of a product, making it a huge challenge indeed.

Understanding the value

In making feature decisions, the most important thing of all is thinking about value. It’s always about value. Below are some considerations that will help you better understand the value of a feature:

This will translate into how much users will get from each feature, and potentially bring into consideration many other features as well. There will definitely be some questions that will arise and can only be answered by user research, advise from subject matter experts and more.

Understanding the importance

The next step will be to scope up each feature, to better understand how important each of them are, below are some considerations to help better understand the importance

This will provide a better picture on the overall scope of a feature, allowing further discussion on prioritising them.

Understanding the priority

There are many prioritisation techniques out there like Priority Pokers, Kano Model, etc. My personal favourite is using the MoSCoW Method, the excerpt below is copied from Wikipedia:

MoSCoW is a prioritisation technique used in business analysis and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement – also known as MoSCoW prioritisation or MoSCoW analysis.

According to A Guide to the Business Analysis Body of Knowledge, version 2.0^[1], section 6.1.5.2, the MoSCoW categories are as follows:

• M – MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
• S – SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
• C – COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
• W – WON’T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

But the tricky part is to prioritise each feature is to put aside personal opinions, bias, perfectionistic thinking and other matters, but being laser focused on the value and importance (outcomes from previous steps) of the feature to the user and your business, and “ruthlessly” assign a priority against each feature.

It’s easy as that!

In theory at least. Sorry to say its usually never the case and its an endless challenge and balancing act.

The guidelines listed above are by no means the ultimate guide to making feature decisions, but I’m a believer that by asking the right questions, considering both value and importance in prioritising features, teams can work together and ideally reach solutions that meet the needs of users and justify it by providing ROI to the business. Just like how mouth watering dishes loved by customers are loved by the business as revenue generators as well.

Feel free to share in the comments if you find these guidelines to be helpful!

So…is it a quality or usability bug? But wait…quality means usability as well no?

I was thinking a lot about the difference between the testing done by Quality Assurance/Testers and User Experience Designers, many have different perceptions and some might argue that its the same thing. It’s tough to draw the line sometimes but I personally would agree to disagree because they share similarities in some areas but are vastly different in objectives, approach, required expertise, and much more.

Difference between testing by Quality Assurance Testers and User Experience Designers

It’s easier to have them as a crude comparison chart, so look below:

But sometimes quality assurance testing also reveals issues in usability…right?

Yes, indeed. Especially when stepping through scenarios in testing activities such as regression testing. Having regression test scenarios based on a solid set of personas would also add to the likelihood of stumbling upon usability issues.

But notice the key word here, these usability issues are usually stumbled upon. Of course if the QA has time, he could also change his objective and attempt to look for usability issues. He will definitely find some, but the issue here is he would most likely know the system inside out, he would most like be technologically savvy, which in turn means it is likely glaring usability issues will be missed out.

Put the system in front of a real user, and all hell will break loose. Small details like being confused on what to do next, lack of clarity in validation input, confusion of captions, they will all emerge.

QA testing has never, and will not be, a substitute to usability testing.

I’ve got a bright idea, can I combine the use of regression test scenarios and scripts for usability testing as well?

That’s a great idea, in fact its a great starting point for usability tests, only if the regression test scenarios are based on key user journeys. In fact, if approached in a structured manner, usability testing could arguably help shape regression tests as well.

But its also highly unlikely they share the exact same scripts and even scenarios. As they differ in their objectives, audience, context, and much more. Its highly likely that it can be initiated with a similar starting point, then progress in different directions.

Does that mean I can live without usability testing?

Yes, definitely. Users can still perform the functions delivered. Don’t think you need to bother optimizing stuff for them.

That’s a valid argument, before even bothering with usability testing you should probably be first asking yourself some of these questions:

1. How high impact is the project? How many users does it have?
2. How complex is the project? Is it just displaying (Reading)? Or is it complex (Loads of CRUD)?
3. How important is customer satisfaction? Meh or do you continuously need to please them for retention (think subscriptions) purposes?
4. How is the competition like? Super tight or you’re monopolizing the market?
5. Will your organization be able to react in time if an iPhone like usability focused product appears and compete with you? Failing to react is equal to going the way of Symbian.

There is no clear right or wrong, there are far too many factors so I’ll leave that decision to you.

Ending stuff

If you’re still reading this hopefully this helps. Feel free share what your organization does and what you think about it in the comments.

Remember the time when you landed a brand-new UX design role, project or job? There could be like a hundred features to build. It could be a legacy product that needs to be revamped, or a greenfield project that needs to be built from ground up. Everyone could be moving in different directions. Stakeholders have high expectations. Everything design related is in a mess.The previous designer left the company with a gaping void or… worst, developers were doing UI design. Add to the fact that requirements is in a disarray and features are being built and rebuilt again continuously. Decisions keep changing.

Sounds familiar? Sounds like the norm in many software companies out there. Oh and to add further salt to the wound, you’re the only user experience guy in the team.

Where on earth should you go from here?

About the series

The "UX Team of One” Series is a set of articles aimed to gear you for war when you’re faced with the situation of being the user experience team of one in big software projects. The key focus will be on practical and cost /time effective approaches to deliver clear UX-related results.

Understand everything

Photo courtesy of flickr user Robaat Williams

Understand everything about the project. Or at least try to. Instead of stating the obvious, lets focus on the absolute bare minimum:

1. Project Mandate – Read it, then read it again to understand the core objective of the project inside out, this should provide an understanding of the big picture of the project.
2. Identify the core feature – Get to know the one core feature that would very much decide the success and failure of the project (Pro-tip: It’s usually ROI related), instead of spreading your net too wide and have a go at understanding every single planned feature (which is virtually impossible).
3. Ask questions – Do not hesitate asking questions to understand more, get opinions, speak to users and make sure to keep the conversation going.

Analysis

Photo courtesy of flickr user CannedTuna

Take time to go through and analyse all the information you got and spend some time going though what your competitors are doing. Have a look at their product screenshots, training videos, demos, trials, whichever you can get your hands on. Also look at some awesome software out there as reference (Sites like Facebook & WordPress are high on my list of beautifully designed software). Critically analyse these areas from a user’s perspective and ask questions on behalf of them, some examples below:

• Display information – Are all these information useful to the user? Are you facing information overload? Is there a more efficient way to present certain pieces of information? Is it easy to get the information you need?
• Input – Is it easy to enter information? Is every input necessary? Is there a better way to ask for input? Are the captions confusing?
• GUI & Interaction – Does the UI look suitable for the context? Is navigation easy? Is it easy for users to meet their objectives? Are the fonts too small? Do the icons on buttons make sense?
• Processes – Is it necessary to have 10 steps instead of 3? If I am in step 1, is it clear to me that there are 3 more steps to go? Why did they choose to do it in this way?

Swipe out your trusty sketchbook and note down your findings, and sketch away some ideas before you forget them. Draw mind-maps, layouts, controls that might come in handy and much more. Emphasize on elements that relate to the core feature you have identified. Remember the key here is to see what they’re doing right, and what they are doing on, these will all be valuable in establishing a starting point.

Visual design mock-ups

Yes I do mean jumping straight into producing some visual designs for…none other than the core feature you have identified.

Based on the knowledge you have gained on the project and enough information on what others are doing, it’s time for you to have your go at designing the end product so roll up your sleeves, whip our your user interface design hat and launch your design tool (My personal preference is Adobe Photoshop) and get started on designing everything from ground up.

It is key to be detail-oriented (aka perfectionist) here and take into account everything from colours, fonts, layouts, controls, backgrounds and everything else. Remember that the sample data you present here has to be realistic as well so make sure those lorem ipsum paragraphs are are not used.

Personally I prefer designing stuff with limited feedback from others until I’m done, this allows me the chance to present a fresh perspective to things without being influenced by the thinking of others or any fall-back to existing solutions that might not be fit for purpose.

In essence, feel free to make quick decisions straight up and only asking others if absolutely necessary, the key here is getting the mock-up done as fast as possible. Below is a good example of a mock-up I’ve got from Flickr:

Photo courtesy of flickr user Nathan Pitman

Show & tell

Photo courtesy of flickr user Tobias Toft

It’s now time to step through mock-ups with the software development team and potentially the stakeholders and customers as well.

Allowing them a look at the “potential-end-product” (through the mock-up you designed) is the best blessing you can ever give them, even though they will be returning the favour by telling you exactly which bit they don’t like or how bad your designs are. Which sounds sucky but is not necessarily a bad thing.

Remember that the objective here is not to have the full-design the actual end product up quickly, which is virtually impossible, but to have establish a starting point for the product. The interface is the end product to your users.

It will also be useful in being the key also help in unlocking a few things:

1. An aligned focus – Rather than busy worrying about every single feature, the focus will now be on this “potential” end product and establishing a starting point on what to do and how to get there.
2. The best idea – Or the best idea at that point. Having decisions will only do good in spurring the team forward. It’s normal to come back with a much better idea at a later stage as iterative improvements are very much the expectation of the software industry these days.
3. Hidden requirements – You’ll be surprised to find that everyone was having their own thought of the product, and how different they are. With this the team can also uncover hidden requirements and action them accordingly.
4. Early feedback – Stakeholders and customers are given the chance to give feedback early, which means much less wasted development/design time.
5. Better prioritization – This opens up the possibility of making a more informed decision in prioritizing what feature should be built first and how things will be progressively introduced
6. Potential risks – Technical risks like performance considerations, integration issues, scope creep and many more could also be potentially noticed early in the software development lifecycle and actioned accordingly.
7. Expectations management – Giving visibility of how the end-product is being progressed will be priceless in expectation management as it allows the management to give visibility to stakeholders and customers on how the project is being progressed even at the beginning phases of the project.

Outcomes

Sweet. You have effectively assisted in establishing a starting point for the project. Now it’ll be a matter of iterating and improving on the project and continue to getting the ball rolling. We’ll talk more about that in the next chapter of the “UX Team of One Series”.

Do share if this article is helpful to you. It would be awesome if you UX people out there could also share your thoughts on other approaches and solutions on getting started with software projects as well.

Just gave this talk the other day on “Real World Prototyping” in Tech Insight 2011 (which was indeed a few months back), and being mean and all, I promised the attendees that I’ll be uploading the slides and sample applications soon.Guess “soon” took quite some time to materialise, stuff came up, RL and all.

Without further ado… below are my slides from the presentation.

Below are the links to the samples I cooked up for this presentation.

In due time, I’ll probably get some explanations and step through the samples in detail through future blog posts so stay tuned!

Tech Insights 2011 is coming to town and happening this week!

I will be delivering a session titled “Real World Prototyping”, which will be at Wednesday (16/11/2011) at 10am, below is the blurb for my session:

If you are…

• Failing your user acceptance tests?
• Dealing with stakeholders that see to believe?
• Finding a lot of development rework due to bad requirements?
• Facing issues with consistency in software user experience?

Not to fear, here comes prototyping to the rescue. Come see how effective prototyping in real world software development can help resolve many of these issues, with a demo heavy session stepping through scenarios of how Expression Blend – Sketchflow is used to rapidly create prototypes to facilitates better communication, requirements, expectations, software and ultimately deliver a better and more engaging user experience.

This session will be targeted at a developer, business analyst and project management audience. I can assure you it will be packed with demos stepping you through how Expression Blend’s Sketchflow – a world class prototyping tool, can be used to enhance your whole software development lifecycle and deliver better ROI to you, your organization, and your clients.

I’ll be uploading my demos and slides up here after the event as well so stay tuned.

There goes my shameless promotion. Hope to see you there!