The second view includes an understanding that technical accessibility by itself is not enough, and that a designers goal should be to produce a usable-accessible experience for users of AT. It goes without saying that I believe in the second view.

So, when designing implementing a megamenu, providing a usable-accessible navigation experience for users of AT poses some tough design challenges.

Considering the kind of users who may visit your site you’ll find that some users may have perfect sight but be unable to operate a mouse, while some may have partial sight but be able to mouse effectively and others may be completely without sight and thus restricted to a screen reader an keyboard-only navigation.

Ensuring a usable accessibility solution for this audience requires that we first understand the usability issues the a conventional megamenu design will present to people in this group.

For sighted, mouse-capable users, interaction with a megamenu may be a component in the process of achieving a task, be it seeking a definite article of information or completing a transaction. For example, on a local authority website: Pay a council tax bill, or, find out about local recycling programs. Observing a sighted, mouse-capable user interacting with a mega menu the user journey may appear to be:

• Based on their goal, the user will decide which top level item will most likely lead them towards achieving their goal.
• They will move their mouse cursor to that item. They may understand from a triangle graphic that hovering or clicking the item will disclose a dropdown men. Regardless, the act of hovering over the item shows the user’s intent to explore the content beyond the menu item.
• After a short timeout the menu panel will be disclosed, and the user will see that this has happened.
• Pre-attentive visualisation and Gestalt principles of perception define that even before the user begins to scan the panel they will already have perceived that the content of the menu is grouped into distinct areas.
• The user will begin to scan the menu for a link that will most likely allow them to proceed further towards achieving their goal. They may initially scan the category titles then move onto scanning links within a specific category, but it’s most likely that they will scan only part of the menu and click the first link that appears to be a good bet.
• If the next page seems relevant to their task they will continue to scan headers, local navigation and associative navigation within the page for the information they require or a link which will take them further towards their goal. If they find page is not relevant to their task the user may click the back button or re-open the initial menu panel and chose another link.

For many disabled users the actual user journey will be the much same as it is for sighted users. But unless care is taken, a technically accessible implementation may not be provide the same level of usability the visual and interaction design affords to non-disabled users.

For instance: The HTML of the menu items and panels will be coded in a way that places the links in the menu panel directly after its parent top-level item. For sighted users this isn’t a problem, the panels will be hidden until they show the intent to open them. Yet for keyboard-only users this best-practice coding will result in having to tab through every sub-item in a panel before they eventually reach the next menu item. Imagine having to press tab more than 100 times in order to reach the menu item form the Recycling section – what would that feel like?

Although without a doubt this experience would be tedious and frustrating for sighted keyboard-only users, imagine further that a completely blind user wouldn’t actually know the Recycling menu item existed until they reached it and the link was read aloud by their screen reader. In a list of 100-plus links, the single word ‘Learn’, isn’t going to mean much. A sighted user would see that Recycling is a top level item, a screen reader user would not. They will not have the benefit of visual design to help guide their decision making process.

A solution to these usability issues is to provide users of assistive technology the same affordances and experience the visual and interaction design provides to non-disabled users – but in a format that can be communicated through AT.

Lets look at two features which would help out our the users of our megamenu.

Feature 1: Screen reader-only content

A sighted user can see the top level menu items are top level menu items, and see that they belong to a group of top level menu items that that form the global navigation bar. A sighted user can see that a menu panel has been disclosed. A sighted user can see that the menu panel is organised into categories and that links are children to the category.

These same affordances can be passed to screen reader users by providing screen reader-only labels that describe links, and and add cues to help them explore the megamenu.

Consider these examples of what needs to be read aloud to clearly translate the context, which the visual design otherwise provides, into a format suitable for screen reader users.

So, navigating the Learn section with a keyboard and a screen reader would sound like:

• “Waste management. Top-level menu item”
• “Household waste. Menu category”
• “Collection schedule”
• “Removal of bulky items”
• “Disposal of chemicals”
• “Recycling. Menu category”
• “Recycling programmes”

And so on.

The additional content should not frustrate returning screen reader users, as many will only listen to the full text of a link if they are unfamiliar with the interface. New users will listen to the full link and description, users familiar with the interface will listen to only the first few syllables before clicking or skipping the link.

Feature 2: Enhanced keyboard navigation

Enhancing keyboard navigation can help improve the navigation experience for keyboard-only and screen reader users who would otherwise have to tab through the full contents of menu panels to reach the menu item beyond.

The solution is an enhancement rather than an override of what would be expected behaviour. This is important as overriding expected behaviours would result in an unpredictable experience that could ultimately confuse and frustrate the very users the solution was designed to support.

So, as would be expected, focusing on the first menu item will disclose the associated menu panel and pressing the tab key at this point will move focus to the first link in the panel.

The enhancement comes into play by allowing users to move the focus directly through items by holding shift and pressing the left and right cursor keys.

Two key requirements which will help make this enhancement discoverable are:

• The functionality must be explained in the accessibility help section of the website.
• The functionality must be integrated into the spoken labels. So the browser would read, “Waste management. Top-level menu item. Press tab to explore, or shift plus cursor right for the next menu item.”

This enhancement is becoming more common on the web. High-profile implementations of this behaviour can be found in the tabbed dialogs of Microsoft Windows and Apple Mac OS X. On the web it can be seen in an ARIA enhanced tab menu on the Yahoo! homepage.

For me the biggest change from 2011 is that I now find myself located in London. In 2009 I was an out-of-towner stepping briefly into the ongoing conversation that is the London UX community. As of last week I’m a fledgling Londoner who will be diving in at the deep-end. For me UX London 2011 represents my first leap from the metaphorical springboard.

The 2009 conference was massively valuable. The workshops I attended changed the way I worked. Peter Merholz’s Product strategy and planning tools have been invaluable in keeping my projects focused, free of scope creep and, ultimately, successful. Richard Rutter and James Box’s Wireframing Web 2.0 for Design and Definition transformed the way I communicate design, releasing me from the straight-jacket that is Visio and letting my clients to experience interaction design in a way technical documentation could never allow.

It’s interesting for me to consider how this year my workshop choices will quite different to those I made in 2009. There will be less technique and more of a leaning towards managing UX, communicating insights, collaborating with business stakeholders and defining intangibles.

At this point I’ve got my eye on:

• Kim Goodwin’s Leading UX.
• Steve Baty’s Communicating Behavioural Insights.
• The Reiger’s It’s not the device people are after, it is all the things the device enables….
• Sunni Brown’s The Art of Graphic Facilitation.

We’ve are lucky enough to have been accepted to exhibit our product at the EIE10 event at Edinburgh Uni next month. Aalong with numerous other exiciting startups we’ll be showing off our wares to investors, technologists, designers and business people.

I had failed to plan for the pitch, and thus planed to fail. It all seemed to make sense in my head, until I stood under the bright studio lights and essentially forgot everything I wanted to say (finding time for your startup side-project when you’re a fully-booked experience architect is HARD!).

The chaps doing the video production were kind, patient, and very helpful. In the end, after about 30 wet-runs, I got a half decent take in the can.

As you can imagine the script is now burned into my brain. Here’s what I said…

Hi. I’m Andy Bright, experience architect for Muxster.

Muxster is a new promotion platform for musicians. Our product empowers artists to take control of the content they already publish to the social web, collecting it into a free zero-maintenance website from which they can generate direct revenue from merchandise and download sales.

We want to banish the legacy of poorly produced, infrequently updated artist website and give musicians control over their content and the conversations happening around it.

We’re really excited to see what people are going to build with Muxster.

An example we imagine is of a band who are releasing a new album and have decided to do a live webcast to celebrate the launch of it.

Muxster provides the platform to host the webcast, include updates from the real-time web and make merchandise sales to their audience all from the same screen.

We look forward to seeing you soon at muxster.com.

…Could have been worse

Here’s my entry:

In a recent UIE podcast Lean Buley of Adaptive Path suggested that paper wireframes are an awful design tool. She describes a familiar scenario in which a designer takes their pre-defined list of required functionality and plops their ideas straight onto pages in a drawing package. She then goes on to note the problem with this situation is that it reduces the design process to the act of pushing shapes around a page.

She’s right. I’ve personally sat in an ad hoc meeting where a senior designer has brought people in to help them push these shapes around. The whole time I had to resist to impulse to say ‘this isn’t design’, ‘ watching your copy and paste isn’t creative’ and ‘I don’t know what the right label is, we should do some research to find out what the users think’.

Why they suck

• They’re too high-fidelity. There is something too definitive about wireframes produced as client-facing deliverable. It’s hard to question something with hard lines and neatly aligned annotations. It’s hard to question something that has obviously taken considerable time to produce and would take a great deal of effort to iterate.
• Nobody understands them. When someone describes an idea for a website your mind starts reeling and your subconscious instantly provides a crystal-clear fully-realised vision of that idea. Alas, everybody has a different vision in that scenario, and your wireframe of that vision is vague enough to allow everyone to visualise a different endgame. You can’t build consensus from a paper wireframe.
• You can’t test a paper wireframe. I’ve read a lot about paper prototyping. High-end design firms like IDEO and consultants like UIE tell tales of how you can put users in-front of paper prototypes and run user tests. I’ve tried to do this. But I’ve always ended up with pieces of paper flying all over the place and had no real idea of what was going on.

A case study

I worked on a project last summer where I was designing an extension to a client’s site. I’d just been to UX London and attended an HTML wireframe workshop with James Box and Richard Rutter.

I was in an agency at the time and as agency people will understand there was great pressure to get anything-at-all out to the client. I decided that annotated paper was the way to go. It would take 4 hours to produce paper wireframes while HTML would take maybe 8. Bada-boom, 4 days late, I get a PDF to the project manager.

A little later on a word document full of questions and as long as my arm came back to me from the client. ‘What’s the user journey here?’, ‘What happens when a user clicks on Show 20 results?’. The client didn’t understand the wireframes. Or, at least, they couldn’t understand the behaviour they should have represented. And I don’t blame them. The wireframes were a shoddy visualisation of my personal mental image.

It took me a total of 6 hours to respond to their questions.

On the way back from UX London I built a HTML prototype of the site for fun. It took about 6 hours. The duration of the east coast train journey from London to Glasgow.

When more feedback came it from the client I decided to build it into the prototype and send it over. Surprisingly they understood it straight away. With the prototype they could ask themselves questions about behaviour and immediately test to see if the prototype could answer them.

Paper wireframes plus written responses 10 hours. Prototype 6 hours.

How it should be done

The right way, or should I say the RITE way, to work with interactive prototypes it to put real users in-front of them.

As Steve Krug suggests, a user test on a site that’s already designed and about to launch isn’t a user test – it’s a disaster check.

If you can go from some early pen sketches to an interactive prototype which you can run user tests on you may learn that your design doesn’t work. It’s best that you find this out before you take it to your development team and waste an awful lot of money.

• You’ll save money
• You’ll save time
• You’ll build something better

I hope to write more about how I prototype website and apps on the future, and release a bunch of the code I use. I actually don’t use any of the commercial packages (although I’ve tried Axure). Just HTML/CSS and Javascript. I do this for two reasons:

1. Nothing behaves more like a plain old HTML/CSS/JS in a browser than plain old HTML/CSS/JS in a broswer
2. jQuery is easier to learn and more powerful that any interaction scripting I’ve seen in prototyping apps to date

Get in touch if you’d like to share stories of how you’re prototyping.

There is a seal on the lid. I’m often running for a train and a bus, and the last thing I wan’t is a big brown stain on my grey chinos before a big meeting!

The cup is double-walled and has an air cavity. Keeps the coffee hot and my hands cool.

A loyalty card is built into every cup. They’re thinking about your future relationship with their business, and know you’ll appreciate the gesture.

The proof of purchase stamp is attached to to cup. The service designers have been at this one. Forgot to ask for a loyalty card stamp? You won’t miss out.

Throw in the price (£1.09) and the fact that it’s ‘just drinkable’ and it’s a no-brainer for me. Thank you to the team of expensive service and product designers who built this cup.

They’re looking for someone with the grits to take them from scratch to app. It’s a true startup chief technical officer role.

You would have the opportunity to get involved in the whole process of bringing the app to market – from ideation, prototyping, usability testing, through to choosing, implementing and scaling the right web stack for the job.

Check out the job spec. and get in touch with them before the 18th of November if you think it’s a match for you.

Looking for a developer to join a core team of an amazing project, someone that practices things like:

• MUST have experience with the Methodology (with a capital M!) of MVC development, agile release cycles, working from user stories,
• Someone that loves coding, loves to play with a range of languages such as Ruby, Phython, PHP, Java etc
• Experience with test driven design a plus – (cucumber, rspec, shoulda, etc)
• Agile-Fu skills. Understands working with user stories, iterations, release early and release often
• Live and be around Glasgow, we need you to work closely with the core team to build things quickly
• Desire to participate and collaborate with designers in generating concepts, prototyping, sketching, user testing, workshops, etc.
• Understands deployment and hosting of website, basic sys-admin-fu skills
• Experience with deploying and maintaining applications through cloud / virtualised infrastructure, with services such as Amazon AWS, RightScale, etc

We’re looking for someone who will actually come in and be part of the company, and work with us to make mypolice something great. We need someone with experience, commitment, living in Scotland and who has been through the experience of setting up or being part of a business before.

We want our developer to work with us not for us, so we can look at alternative ways of building the site. The right developer will have the freedom to innovate around the technologies used within the project. Basically our developer would be a co-director and have a large input on the shape of the site.

We want someone who works well with designers to create common understanding and language.

We’re offering an immediate start.

Salary 25 – 30K.

To apply send us a link to your portfolio, linkedin, sites you have created and we’ll go from there!

Interest for this opportunity closes on Wednesday 18th of November.

Sounds fun!

Design games

There won’t be any slides to follow, but I’ll put some illustrations up on a whiteboard to reference. The session will focus on a single hands-on activity, so be prepared to roll up your sleeves and work as part of a team.

I’ll set the scene by explaining the background of a project I’m working on. I’ll take a couple of minutes highlight some of the problems the design team is facing surrounding the large number of project stakeholders and I’ll talk about how we’re using a design game called Design the box as part of the solution.

Tonight we’ll split into 6 teams to design the box for techmeetup. I’ll distribute an A2 template (which I’ll take away to make-up) and 2 markers (which you can keep) to each team and 10 minutes will be put on the clock for the challenge.

After the 10 minutes of work each team will get 60 seconds to show and tell about their work.

If you’re lucky your box will be as bad-ass as this Gumtree one I made a couple of months ago…

If you want to build better, usable and successful software: observe people using it.

You don’t need a plan, or a script, or a schedule.

Right now, today, you need to find someone who isn’t on your project team, sit them down and observe them using your software.

When James, Nick and I started working on our platform for musicians we generated reems of design concepts as we thought through the possibilities for our app. In some ways we did well in reigning-in our imagination, pulling back on the most complex and nice-to-have features. But as we’ve continued to develop our product it’s become obvious that we’ve still left too much in the mix, and are now commenting out swathes of hanf-baked code in order to keep the app simple and launch-date achievable.

The google way

For our work on Muxster we’ve taken some inspiration on design strategy from the Google Chrome for Mac team. With all of it’s projects Google always puts the user first. They believe in user-centered design so strongly that they’ve written it into their company principles, and you’ll agree that it’s a guideline that’s served them well. Like us the Chrome team are in a position where they want to ship their product as quickly as they can but still deliver a great user experience.

They plan to achieve this by launching the app early, but with some highly visible feature omissions. The first versions will include a functional, quick and reliable web browsing experience but omit major features such as printing and browser plugins. Google has decided that it’s better to limit their team to delivering a few features really really well rather than a slew of features in a slipshod manner. They’re putting “half, not half-assed” into practice.

Our plan for beta is to have a very polished main-window experience with large, obvious features missing instead of a broad, partially-implemented experience where everything feels shoddy and half done. We feel this is a much better trade-off as it makes it very clear what is done and what is not. As a result, as new features are added or bugs are fixed, anything that doesn’t look finished/polished stands out like a sore thumb and gets immediate attention. In the other world, it would blend into the general suck and we’d never tell when something regressed. – http://dev.chromium.org/developers/how-tos/mac-detailed-status

It’s straightforward to see how this strategy will work for the Chrome team. The initial beta release will mostly be downloaded and installed by early adopters. These are the kind of people who’ll already have two or three browsers installed on their Mac and will overlook the lack of printing for the chance to get their hands on the next big thing. If the core browsing experience is compelling enough this group will happily tell their family and friends about Chrome when they feel it’s ready. So when printing eventually makes its way into the stable version the early adopters will urge those they know to give Chrome a try.

Our plan with Muxster is similar. We’ll release a cut-down version into the wild and observe the reaction. It’s not worth keeping the app to ourselves as we continue to pile in features. Especially as we expect many of the features we’ve already built will be removed from future versions as we continue to observe the results of usability testing.

What about difficult clients and the quest for billable-hours?

You may agree that I’m talking some sense here, but if you do any client work you’ll surely want to remind me that “the client gets what the client wants”. That’s a fair point. It’s difficult when stakeholders are fighting hard for their piece of the project and their vision of what it will look like.

Yet, it’s wrong to just deliver simply what’s asked of you. In most cases, if your you’re taking design direction directly from a client, relationships will be strained and your project will almost definitely fail.

Some projects are complex, with many moving parts and difficult problems to solve. Some project objectives are complex, and this where it’s necessary to understand and accept that they may not be achieved in one development cycle. Successful projects need design strategy, honest planning and achievable development cycles.

Design strategy tools

I attended a great workshop at UX London by Peter Merholz of Adaptive Path. He was presenting a condensed version of a full day workshop from UX Week. The focus was on the cornerstones of good design strategy i.e. focus, definition, customer value and project scope.

Peter explained some of the design strategy tools Adaptive Path use when working with their clients. The tool I though was most valuable was a method to prioritise opportunities (i.e. features, etc.).

I’ve mentioned the folly of promising stakeholders everything they want. This tool offers a way to generate an achievable project scope that everyone can get behind.

Prioritising opportunities

Within your formative work you and your stakeholders will have generated concepts and ideas about how you may achieve the project objectives.

It could be that you’ve decided that you could build a social web app which leverages collective intelligence, virility and includes a mobile version which features location-based functionality and some augmented reality magic.

This is of couse a joke. I hope there isn’t a team out there that would actually try to build all of that in one development cycle. We need to prioritise. We need to understand what’s actually important and what’s viable.

Availability opportunities will vary depending on your project. In the example Peter gave we were looking at higher level opportunities for a hotel chain; increasing repeat visits, reducing operating costs and increasing revenue per customer.

We’ll start by collecting opportunities together and rating them on a scales of importance and viability. We’ll allow ourselves 18 points to spend on each column. These points represent the effort we have to spend on the project.

With this table we’ve articulated our understanding of what’s important for the project and also thought about what’s actually viable. When using this method with stakeholders you’ll appreciate the points limit, there’s only so many points to play with so they can’t give each opportunity 5 in both columns!

If we plot our results out on a chart we can use to help us visualise where we should focus our attention.

The slices across the chart basically visualise the what your must build, what you could build and what you shouldn’t really bother with just yet. Here, A and C are must haves. B is a maybe. While D E and F are not worth the time at the moment.

This is only one of the first steps in defining your design strategy, part of the focus stage. From here your’ll need to look at what features will go into each of the prioritised opportunities and develop a product evolution plan. What we’ve done is look top-down at what’s most important and viable, but you shouldn’t take your top opportunities and expect to deliver them all in one development cycle.

The next stage of developing a product evolution plan will allow you to spilt you features into discreet development cycles. Perhaps you’d choose work on the web app first, then in the next cycle get the first mobile version off the ground and in the third cycle add or remove features from both. With each release moving closer to achiving the vision of the initial strategy.