Why I dislike them

They’re something of a fashion and used because they ‘clean up the design’. Now, there’s nothing wrong with that. My problem is when a design pattern is inappropriately used.

Go-to design pattern

My beef with drop-downs :

• ‘It makes the site look neater’
• If that’s the only reason you want to use it, you better think about the problem a bit longer.
• You’re focusing on personal preference in design instead of thinking about your users. If a persistent secondary navigation will and can work, use that instead.
• Your information architecture may not be defined appropriately if you have so much that you need to hide it.
• ‘I like drop-downs and they’re used on software packages all the time’
• That’s true, but software packages employ a different mental model when they’re designed. They focus on learned behaviour and assume that the user will spend some time with the application. On a website it often means that the user is confused. And a confused user is never a good thing.

Note: Yes, those are actual examples I’ve heard over the years to qualify drop-down usage.
The short answer is: I dislike any design pattern, when it’s an inappropriate solution to the design problem.

Inappropriate use

Hide information critical to the user goals or business requirements.

Example: protonode – this website

Secondary goal: Showcase my skill set to prospective employers the drop-down contains navigation items to my work examples.

No visual cues to indicate secondary navigation

Onmouseover event

Not a complete failure – band-aids for this problem

• The section landing page has links to the different pages, so the user isn’t blocked from completing a workflow. But it’s not an optimal solution. If you’re on any of the detail pages in the section, you need to remember to navigate to the rest because there aren’t any signposts visible.
• A visual cue on the primary navigation would have aided the user experience.

Appropriate use

Hide information

It’s tricky to explain generic cases when hiding information is the best solution and I’m sure I haven’t thought about all the scenarios.

Quick links

Providing action links to users where the information architecture is well thought out.
A large section of the user base is familiar with the website and can afford spending time learning behaviour.

Example: Etsy

Etsy navigation header - normal state

Drop-down: the information architecture is very clear and the drop-down links to specific user actions. It greatly improves the usability of the website.

Large datasets are represented

The most common use I could think of related to hardware. E.g when you’re looking for a specific type of phone.

Example: Samsung

Initial state of the website

Secondary navigation

Tertiary navigation

I like Samsung’s website solution. It covers the bases in having a structure that people understand, and allowing them to narrow to the product type they’re looking for.

Narrowing a dataset

It’s a trend we’ve been seeing for a couple of years in search. Allowing the user to narrow the category they want to search in.

Example: Amazon

Amazon - search drop-down filter

Models real life

The information is organised in a way that you’re used to encounter in real life. The information design utilises a mental model you’re used to encountering in real life aiding the user to find something specific in a huge dataset.

Example: Tesco

The information is modelled to real life experience

Secondary goals

This is the most common use for drop-downs. It allows the user access to important, but not necessarily critical information paths. I include it for completeness but it encompasses other points, like quick links and expanding data sets.

Mechanisms

In addition to when a design pattern is appropriate the manner it functions in a deal breaker in assuring that it works well for the user.

• Display a visual cue showing that a navigation element expands into a drop-down
• Take care with hotspots.
• In functional intensive areas, like a primary navigation bar, the hotspots can be close to each other. It causes frustration of you want to type your search query and your mouse hits the hotspot for search category drill-down
• Make sure the hover area is large enough to keep to the menu a user is looking at. It becomes even more important when you go to three levels.
• Don’t separate the menus to more than 3 levels.
• Having a delay/ fade-in or out can improve the experience.

My golden rule: Know the rules of the system. Understand which ones can be bent and which ones broken.

Further reading

• Drop-down menus – no thanks

• The 3-Ws of drop-down menus
  Good information on the nuts and bolts to consider when/ where drop-downs are appropriate
• Drop-Down Usability: When You Should (and Shouldn’t) Use Them
• Designing Drop-Down Menus: Examples and Best Practices

I’ve spent a lot of time working with companies to make websites that cater for their users and their information requirements. It also means that I’ve done a fair amount of business analysis.

Something I’ve often wondered about is, why some companies/ individuals/ projects are successful – and with that I mean – they make lots of money and go viral. And others, that seem to have a good, solid business case fails. (Can you tell that I’ve worked for a lot of start-up companies?) I think there are many factors, but I think I’ve distilled them to luck, personality and timing. I guess that’s a post on its own. I also wonder about the factors that make someone ‘good’ at what they do.

I’ve been very lucky to work with some excellent professionals, albeit designers, developers, analysts, copywriters, account managers, basically the whole gamut of web professionals, in my life. People that I just loved working with, because they were so damn good. When I think about them, they have common traits:

• Passion (and a willingness to argue their case in a logical manner)
• Lack of ego – they focus on the quality of what they’re working on instead of trying to prove themselves.
• Cleverness – this is quite obvious, but they’re doing something they’re *really* interested in and have a talent for.
• Diligence – one could also call them bulldogs – which, coming from me, is a compliment. They foster the diligence to get something just right, to spend the time to become excellent at what they do. They adopt due diligence. They don’t automatically assume that they’re correct. Instead, they think about a problem and don’t give a knee-jerk reaction.

That leads me to drill down to a more specific thought. Why am I a good information architect? Or rather, why do I think I make good a good information architect?

I’ve distilled that to one point: I have an appalling sense of direction.

Now, I’m too pedantic to give an info-bit as an answer. I believe that I have all the qualities I’ve mentioned under common traits. But the most important when designing the interaction model is, being empathetic.

Why empathy?

It’s not a simple one-liner. It underlines the core characteristics of an information architect:

Mental models:

• You have to be able to adopt their mindset – goal orientation within the system. This is quite easy.
• Social/ cultural norms – understand the cultural factors that may be in play. Using relevant wayfinding cues, or being sensitive with the type of branding imagery you employ in example.
• Ability – both the technical ability and the limitations of that wonderfully complex system we call our brains. E.g. red/ green colour blindness, information retention or learned behavior.
• Scientific – linking up to ability, we’re at a stage where we’re learning more about the human brain and research into what makes us human. Building on the trove of information on human computer interaction/
• Timing – assess whether certain areas of a site will have a time stress or induce stress when it’s being used. E.g. the booking and payment process on airline websites often makes me feel stressed.
• Exception management, standardisation (or divergence from the bell curve) – Yes, you’ve followed all the usability rules. Why should you care because someone does not notice your main call to action based on user eye tracking.

I declare, you cannot be good at interface design if you don’t have empathy. I’ve been lost so many times and places in my life, that I have sympathy when someone cannot decode, what we consider, the obvious wayfinding cues. Discuss!

Sitemap and/or logic diagrams

Then I list all the pages (or page templates) used on the website with the following information

Example:

Title: Payment confirmation page/ Receipt
IA Ref: 0-1.8
Page goal:
Give feedback to user that payment was successful

Description:
Display content thanking user for payment

Show the following information:

• Order number
• Purchaser address
• Purchaser email
• Items purchased
• Product title
• Product image
• Product price
• Total price
• VAT
• Shipment cost
• Total cost

Actions:

• On this page we have operational actions.
• Update company order section to display order
• Send email to user
• Send email to company with order details

Design
Page layout: Content layout page
Email: Need email design

Open issues
Define any questions or actions that need further analysis. I know I did this example from memory and will probably notice some glaring omissions later

I find using wireframes instead of descriptions work better across the project life-cycle.

• During planning
• I list all the questions I’ve come across while planning that the requirement interviews and analysis did not reveal
• I put in assumptions I made during planning so that I can ensure that I got the functionality right
• Reminds me which questions to ask when I talk to the design, copy and development team

During development

• I document which oversights we made during planning
• What changes the environment kicked up

Review
After a project went live I use the open issues as the basis for what problems we came across and how we can amend processes, documentation and procedures to prevent them in future

Status update
I often find them useful for meetings with the project team and stakeholder.

Technical environment

• Specify the programming environment
• How databases will interact
• If there are any third-party software used and how important it is to the functioning of the website (risk)
• Refer to technical specifications to be read in conjunction with the functional specification
• List other companies responsible for developing parts of the website when required

Technical requirements
List any top-level requirements, as well as technical requirements that may affect other team members i.e. when a lot of imagery is uploaded to the site the website layout grid may need to accommodate 3 images sizes for instance. This is important to the designers and front-end developers but a back-end development requirement.

I always include:

• an URL strategy
• A section on SEO
• What software will be used for tracking site visits (on some projects this forms such a big part of the project that it warrants a complete section.)

You may need sections for copy or design depending on the project.

Operational information

• Both for the technical system and for the company if you’ll be involved with the project when it is live.

• Who’s responsible for which operational aspects i.e. the website manager in the company is responsible for managing the content on the website content management system. What is the support structure within your company if the site goes down. (Service level agreements form part of the project contract and should be given in detail here.)

List other companies that are:

• responsible for part of the development
• has to do work i.e. search specialist company helping with social media and SEO

Success metrics
Not always included – it depends how closely the company is involved after the website goes live

Risk analysis
This is the place to reiterate any concerns, conditions you set out in your project costing.

I tend to edit this section a lot throughout the life-cycle of the project as certain obstacles are cleared and new concerns come to light.

Open issues

• Logically this section links to the risk analysis. I find this section very useful over the project life-cycle.
• During planning
• I list all the questions I’ve come across while planning that the requirement interviews and analysis did not reveal
• I put in assumptions I made during planning so that I can ensure that I got the functionality right
• Reminds me which questions to ask when I talk to the design, copy and development team

During development

• I document which oversights we made during planning
• What changes in the environment kicked up

Review
After a project went live I use the open issues as the basis for what problems we came across and how we can amend processes, documentation and procedures to prevent them in future

Status update
I often find them useful for meetings with the project team and stakeholder.

Functional specification – getting down to business
After writing the top-level information about the project we get to the project functionality itself.

Sitemap and/or logic diagrams

Then I list all the pages (or page templates) used on the website with the following information

Example:
Title: Payment confirmation page/ Receipt
IA Ref: 0-1.8
Page goal:
Give feedback to user that payment was successful

Description:
Display content thanking user for payment

Show the following information:

• Order number
• Purchaser address
• Purchaser email
• Items purchased
• Product title
• Product image
• Product price
• Total price
• VAT
• Shipment cost
• Total cost

Actions:

• On this page we have operational actions.
• Update company order section to display order
• Send email to user
• Send email to company with order details

Design

• Page layout: Content layout page
• Email: Need email design

Open issues
Define any questions or actions that need further analysis. I know I did this example from memory and will probably notice some glaring omissions later

Document audience

• Business stakeholders – one person would be responsible to sign the functionality, budget, timeline etc off. But other people within the client company may be required to be part of the process. E.g. website manager, company owner, CTO and marketing manager.
• Project designers
• Front-end developers
• Back-end developers
• Copywriters
• Management
• Quality assurance team

As you can see it’s a lot of different people that you have to cater for, and it can be quite difficult. The designers, developers and QA team need very detailed information whereas the management will just want an overview. The business stakeholders may not want as much information but they need to sign it off, so you need to make the structure palatable for them too.

In my recent projects I’ve focused on using a wireframe document that I’ve created in Visio but word can work very well. It does not really matter what you use, as long as it conveys the information. Because it is a ‘living document’ you have to be able to update and create it quickly.

My information structure looks something like this.

• About the document
• Audience
• Goal
• Version control information
• Sign-off information

Company overview
Jacqueline Fouche Design Studio is a small business selling handmade jewellery.

Unique selling point
Unique hand crafted jewellery in a style and design that you do not find in mainstream shops.

Company requirements

• Sell and market jewellery online.
• Refer local marketing to her website.
• Create a loyal group of followers visiting the website.
• Little time to spend on the website every day – managing the website will occur in time blocks – like over weekends

Site goals

• Sell jewellery
• Gain a site following
• Market jewellery
• Attract wholesale clients

User requirements

• Find interesting information – tutorials, jewellery information
• Find and buy cool pieces of jewellery

While you go through the public and admin page functionality they will:

• Start drawing out the database structure
• Tell you which aspects you’re missing from a data point of view
• Suggest changes to improve functionality
• Inform you of technical problems you introduce with the functionality you planned
• Its effect on costing the project
• Whether it’s an insurmountable problem and whether you need to change it

In this case, I’m on my own, and even though I majored in Computer Science I’m no programmer. So forgive my puny attempt – but it would look something like this.

Product table

• Title
• Description
• Asset links (thumbnail, medium and large sizes)
• Price
• Size description
• Metric length
• Metric height
• Chain length metric
• Colour

Material table

• Material title
• Material description
• Asset links (medium sizes)
• Note: In this context material refers to e.g. the type of metal used making the product

Techniques table

• Technique title
• Technique description
• Asset links (medium sizes)

Style table

• Title
• Description
• Asset links

Product type table

• Title
• Description
• Asset links

Colour table

• Title

On large technical projects you’ll be lucky enough to have a business analyst working on the data requirements and/or the system architect (head developer) will write a technical specification that runs alongside the functional specification.

In our case study Jacqueline Fouche Design Studio sells jewellery and we need to analyse the information. I’ve already touched on it in this post.

We need to:

• Provide functionality for the business owner to upload product information.
• We have to ensure the site structure conforms to company and user requirements.
• Plan the database.
• Provide a basis from planning out the search functionality

Information displayed to the user

• Product: Jewellery
• Product type: Bracelet ? cuff
• Style
• Colour(s)
• Amount available
• Material(s)
• Size – extra small, small, medium, large, extra large
• Size measurements: imperial and metric
• Price
• Appearance – photographs
• Techniques
• Range
• Note: The jewellery designer creates pieces that form part of a range so that people can buy pieces with a similar look to wear together.

I’ve already decided that I cannot afford my ideal technical solution at this moment. But to illustrate some of the functionality I created this wireframe.

Product Detail - Management Pages

The way you approach a project is always dependant on the requirements of the project. In general I like to have the following at hand when discussing the project with other team members:

• Have the sitemap
• Overall online environment map
• The list with user and company requirements
• The functional specification at hand

Why?

• It makes the meetings easier because you have visual aids to contextualise the problems you’re trying to solve handy.
• It’s easier for them to tell you which things you got wrong in the planning than when you’re trying to come up with a strategy with them.
• It’s less work and more accurate to update the document than just making notes.
• It’s shows you’re respectful of their time as they should be of yours

• In this case I would sit down with the development manager (system architect) before writing the functional specification because I’m concerned about a specific part of the site – the search.
• There is still a concern about budget and whether users will be able to purchase on the site when it launches – or if it will be a separate project later.
• So I’ll need input on that section to do a top-level budget

Other examples of team involvement at this stage:

• Person responsible for the overall budget e.g account manager, project director (main cheese of the project managers), heads of the teams that will be involved or all of the above in an agency.
• Design team
• Front-end developer