Desktop and enterprise software design

September 27, 2016

UX and UI resources, inspiration

Designing Interfaces (Tidwell), book

About Face 2.0

History and design background of Microsoft Word, probably the oldest software still in use.

User Interface Design and the change from desktop computing

(skip the last part about VMware marketing rant; insight into interface trends. Why are apps so much easier to use? Will desktop software look and feel more like apps in the near future?)



Mobile lightbox or overlay

May 13, 2014

Overlays are an aggressive disruptive method of getting users attention. If abused or not implemented properly, visitors may leave the site. Especially on mobile, due to the limited screen size, there are better solutions. As usual it depends on the context and content. Highly recommend that you evaluate the need for a (mobile) overlay on a per-project/per-application basis.

Some applications that could be using overlay (but could be handled with an alternative):

  • Web survey
  • Can I help you chat function
  • Modal dialog message   (if content is limited, say just one line of text and 2 buttons, then these are maybe the only exception for using mobile lightbox)
  • Image slideshow or video preview
  • Content preview  (by clicking a ‘?’ or info-button)
  • Other

Alternative solutions:

  • Fixed-position button that scrolls along while the user moves down the page
  • Fixed-position button appearing at some point e.g. appears only after if the user has scrolled 1 pagelength down
  • Prominent content on the page  (e.g. near the navigation header)
  • Navigate to new page, expand an accordion, slider/carrousel, swap content.  (for lightbox overlays that appear after a user clicks something)
  • Modal dialog. Probably using the alert JS function (TBC if it’s feasible to add links and other rich content)
  • Other solutions

Some principles (if overlay is the only option):

  • The overlay should always be visible in the mobile viewport. It should never be the case that a user scrolls and only sees the overlay background.
  • The close button should always be visible. (must-have).  This is often in the form of an X in the top-right and/or “Close” button, but can be a floating X or auto-hiding X as done in some Jquery plug-ins.
  • Overlay background should be visible so that user knows it’s an overlay that is part of the site.
  • Sometimes it needs to be clearly part of the site (e.g. branded or mentioning company/website name the title)
  • The overlay should be resized and the content scaled down (see some Jquery plug-ins for overlays/lightboxes)
  • It needs to be carefully tested on different devices/browsers. Zooming in and out of the conten should be possible, without hampering the possibility of closing the overlay.
  • Content should be limited on mobile. Scrolling can be problematic.
  • Generally it is not recommended to show an overlay after x seconds, especially if the user doesn’t expect it and didn’t click anything.


General behaviour

  • For regular overlays
    • Clicking outside the overlay will close it
    • Clicking on the X will close it (as is)
    • Pressing Escape key will close it (as is)
  • For modal overlays
    • Clicking on the Close label, image and/or button will close it

Examples and best practice 


A reasonable example is the cookie lightbox of on mobile:

–       Manage expectations. It seems to appear 1-2 seconds after the homepage is loaded, so the user still knows he’s on the right website and can still act on the cookie request. (dispite that lightbox may not be the best solution for cookie permission)

–       Closing. There is a clear, branded “< back” button placed on the top of the overlay, making it quick and easy to close or ignore the message.

–       Flexible. It takes up the full real-estate of the screen and if there’s a lot of content this is not a problem, it can be quite tall.




Because of the limited mobile screen size and the uasbility requirements listed here, content needs to be limited and overlays are often not ideal on mobile. Overlays that are limited in content and user-triggered may be an exception. In any case overlays must behave properly, as outlined in the principles above. I recommend to make a list of on what pages overlays are needed and approve the need for a (mobile) overlay on a per-project/per-application basis. If you have little control over this, offer guidelines (in the CMS or another form) to help the client realise the negative consequences of mobile overlays and offer suitable alternatives. Consider limiting the use of mobile overlays for the sake of conversion and the client’s own sake. Provide a overlay solution that can handle any type of (large) content and test it well.

Layout options

March 23, 2014


When designing you generally have these layout options. Using any of these patterns often will have pros/cons and consequences on the flow and rest of the page design. Possible factors/pro-con considerations influencing your decision are:

  • real-estate  (and fold)
  • visibility/prominence
  • suitability
  • loss of orientation
  • convention versus intuition


Vertical layouts

Vertical tabs









CON: Everything is shown expanded resulting in information overload and clutter.
PRO: No sub-navigation is needed


Accordions   –  popular with mobile  (risks)

Anchor links –

Carousel / caroussels

‘More details’ link (half-way accordion)

Zig zag imagery

Horizontal layouts

Horizontal tabs

Row of links

Row of buttons




Other layouts

Rollover tooltip / toast message


Navigate to a different page

‘next’ button

Progressive menu (or expandable tree)  –  popular with mobile

Filters   (or row of toggles)

Swap content  (flip div)

A combination   –   e.g.

, expand an accordion, slider/carrousel, …  (for lightbox overlays that appear after a user clicks something)


Some things to note


  • Tabs can also look like buttons or large links
  • Re-use page templates  (see Consistency post)
































Other layout options



Further reading:


Axure annotations: show/hide call-outs or footnotes

January 30, 2014

In this article I briefly discuss the possibilities of annotating your designs, with the option of quickly removing annotations when you don’t want to show them in your deliverable.

Let’s face it: Axure doesn’t have an quick and clean way to annotate your wireframes. This can be a pain when you are using your designs for different purposes:

1) you want an annotated version of your designs for functional documentation,

2) but you also want a clean non-annotated version.


Annotation is typically done with call-outs or “numbers in bubbles”.

In Axure the standard way to annotate your wireframes is using footnotes. Unfortunately these footnotes are very small and can’t easily be customised.


Option A – temporary delete/move

Unfortunately there is no quick and easy way to publish an Axure without your call-outs.

The best I can suggest is to temporarily delete or move the call-outs off the screen before publishing. Repeat this for every page you want to publish without call-outs.

with call-outs


without call-outs

Option B – dynamic panels

There isn’t the ease like layers in Photoshop. Axure does have dynamic panels. These work a bit like layers as you can quickly show/hide/move them, even in your clickable demo. But to edit a layer’s content you have to click around a lot  (see demo switching back and forth between the annotation layer and the wireframe layer until the annotation is at the correct position.

If you go for the delete option, then you may also want to use the group feature of Axure. This way you can quickly select all call-outs at once (and then undo the change. Before you start, make sure to save your file as a different version, so that you don’t lose your original call-outs locations.

Option A or B?

I would go for either of these options, depending on the project. I usually just use custom annotations (option A) but then keep the call-outs in my click-demos. That’s because deleting them all just takes too much time. It might not be acceptable for all client presentation though.




Option C – footnotes

Other options like the built-in yellow Axure footnotes/annotations like this: cid:image005.png@01CE200F.E3F0F220  are advanced but unfortunately not easy to maintain. They are also hard to read.


Hope they improve this in the next Axure release!

Gathering feedback

November 26, 2013

Sketchboards, wireflows, story maps and UX journeys

January 7, 2013

Sketchboards are popularised by Adaptive Path. Wireframes as a first step are too slow and detailed. The collaborative use of the sketchboard opens up the design process to everyone involved (all stakeholders including clients, visibility for management). Designers need a quick way to explore many different possibilities of the bigger picture, solo or in collaboration.

Related concepts

User flow –

Sketchboard – your starting point?  “inspirational material such as personas or requirements are used as a starting point to drive the conceptualization process”

Experience map – typically showing the full concept, official deliverable and usually not sketched

Canvas flow

Wireflow – mix between wireframes and user flow

Speech bubbles – used as a starting point per user, or showing the thought processes step-by-step for one particular user, these are annotation elements

Customer journey mapping

The process, coarsely speaking

Caution: first start with a high-level diagramatic flow (swimlane, flowchart, siteflow). Keep the micro-interactions ideas for your own analysis and to inspire yourself. Communicate to the outside what the system interactions will be (and what triggers one user to another) the get agreement on that first.

  1. Get out a big sheet of paper (2-3 meters) and stick it to the wall
  2. Use sticky notes to divide the sketchboard into broad topics like Design/User Personas or steps that your users will take (signup, log in, edit details, close account, etc).
  3. Use paper or the UX Sketchbook to start roughing out ideas or thoughts
  4. Stick them to the board  (DS: preferably everything is sticky and can be moved around)
  5. Move things around

From: Sketchboard before you wireframe – Treehouse Blog

The process, detailed steps


1. Gather the  inputs:

On the left side of the sheet (label it “Input” and optionally draw a dashed vertical line to separate it from the wireflows that sit on the right-side)

– sitemap

– scope items

– objectives

– add criteria  (requirements/user stories)  (

– users  (personas, facts)

– success metrics

2. Sketch, sketch, sketch

Start sketching on separate papers

  • Start with 6-up (A4 landscape) multi-page templates (a.k.a. thumbnail sketches) to explore one problem from different angles, or explore a possible flow  (example) (template)
  • – Focus first on quantity. Go right-brained. Your goal here is to come up with many different ideas or usability solutions without being too critical or pixel-perfect at this stage.
  • – stick them up on the board
  • – “take a step back and think about which one works best. Maybe [it’s a hybrid]. Do another thumbnail sketch if this is the case, then” go for the 1-up template.
  • – don’t use pencils, just scribble it out to not get perfectionist over the details

Then sketch full pages using this single-page template (1-up) to “zoom in” on a particular thumbnail idea with slightly more detail

  • – add headers, visual weight, functional elements
  • – remain sketchy, don’t overdo it on the fine detail

3. Start your sketchboard

  • Divide it into steps that your user will take or stages of user process  (these should be labeled big)

– “Once you’re happy with the position and grouping of your sketches, replace the Post-It headings with inked ones – a big chisel tip Sharpie works well (just make sure the ink doesn’t bleed through the brown paper and onto the wall!) ”

  • Roughly organise  your problems and constraints
  • Optionally add research findings, competitor examples and other inspiration libraries
  • Select, evaluate, discuss, critique, decide – collaborate!

4. Share and iterate

– take it to your team in a tube

– take (seperate) notes for feedback (not on the board)

– go back and add summarized changes as annotations to your board

“During the evaluation sessions, annotate your sketches, use Post-It notes, and amend or create new sketches as required to capture feedback, suggestions and corrections”
5. Start wireframing

– THEN make the wireframes and/or prototype on the computer

Learn more about the process

Sketchboard examples

Screen 00000

Sketchboard - priorities added



UX flow examples



$ Tools

– Drafting dots  (sticky)

– Mobile whiteboards  (lightweight, useful if you lack wall space) or large piece of cardboard

Examples Tip


Related articles

See also:

Types of deliverables WP post

Learn more  TIP videos

More videos @

Ideas, tools, alternatives

A.K.A. : Mindmap, wireflows, wiremaps, user flows, customer flow, user journey, concept maps, ux flow, ux flowchart, and sitemaps.

Prezi (ZUI) is a less linear, more free-form and animated way of telling a story. Alternatively, zoom in manually in powerpoint, or another way to easily navigate in a large canvas.

Story maps (hybrid between storyboard and UX map) @


UXpressia allows you to create digrams they call “Impact Maps”, starting with Personas. The fixed template allows you to add cards and connectors for the following stages: business goals > personas > impacts > deliverables > user stories

Collaborative design workshops



“For complex products, it’s helpful to understand the system at a high level, before anything gets fully designed, prototyped, or built. I like to call this method of flowcharting “wireflowing”. It’s a hybrid of traditional sitemaps, flowcharts, and wireframes. The benefit is that you can start to make UI-level decisions & establish consistent patterns quickly, while maintaining a relational understanding of how everything fits together.


Customer flows: design principles

[Seperate post]

More tips in dashboard design and information design (info visualisation), design for simplicity, etc.


The main focus should be a self-explanatory journey that can be easily shared.

  • Show where it starts (usually upper-left corner)
  • Provide focus, focal point (play with prominence)
  • Split it off into separate posters (don’t cram it all on one page).
  • Try a chronological left-to-right approach, showing the journey from start to end
  • Landscape usually works better than portrait (for both screen and wall viewing)


  • Avoid long arrows, too many arrows. Re-order the screens to fix this.
  • Use too many colours. Be consistent with colours.
  • Use too much text



See my GetPocket (wireflows)  + FB saves

UX journey mapping course @ Safari Books Online

Wireframe checklist

June 19, 2011

In your sketches, wireframes, and (visual) designs, there may be one screen or complex multi-step interactions. Throughout the interaction use this check-list to verify your designs are good.

Did you…?

1. Manage user’s expectations

At every step of the interaction, on every screen, in the flow what assumptions are you making about what the user does/knows or has seen?

Don’t assume:
– the user reads      copywriting
– the user will notice visual elements    visual design
– the user will notice the new visual/UI element your popping up (inline), no matter how in-your-face it is       layout, contrast, line of fire
– the user soaks up the information on the page from top to bottom
– the user knows what to do (next)    call-to-action
– the user understands what you’ve written     avoid jargon
– the user will stick around     persuade
– the user knows the rules or what to do   explain/offer help

The user is focused at one task, when for example filling in a form he/she is in “input mode”. Berry picking and looking for that clue to complete his goal/task. Minimise interuptions and avoid distractions, unless there are designed well enough to guide the user  prevent the user from completing his goal.

– make the user feel cheated
– be vague or ambiguous

But do:
– build a good story, from top to bottom. Still expect the user to scan headers and images that look relevant
– guide and persuade the user
– be clear, transparent
– (give the big picture, reverse pyramid, explain the 1-2-3 process )
– include emotion in any product, show the benefit and experience

2. Cater for all personas and scenarios

Don’t forget the novices (complete beginners) and first-time users! Could your grandma use it (if she’s part of the target group) or the trickiest persona with the least web skills?
Be the user, role-play him. “How did I come here? Where am I now? What can I do here? Where can I go now? Does this intice/interest me or do I want to leave now?”

3. Replace lorem ipsum with real copy
Does stuff still make sense? Product names, prices, long German words.

Label the images, brainstorm what will be shown there concretely.

You usually don’t have to worry too much about the text length, but evaluate the visual design about things like min/average/max text length and word wrapping)

4. Worst-case design
What are the edge cases? What happens if there is zero content, very little or very much content or text? Things can go wrong on rainy days all kinds of rare exception scenarios exist, from the user or the system’s (zero results, time-out, back-end server down) point of view. What about the stress cases? If users don’t know anything about your product or are in a hurry, they still need to use the system quickly.

Other things to check

  • Minimise noise.
    Hide elements which are not relevant to most users. For example don’t place on the login screen long texts about the process to get retrieve a forgotten password. Instead hide it behind a link or help button.
    Progressively show (disclose) elements as soon as a user has indicated he wants to use that, but don’t create large unpleasant surprises. For example if a login and password field is present, and clicking on either will collapse open a new panel with 10 more fields to fill in, that’s a rather unpleasant surprise.
  • Communicate exceptions. Don’t require a click from the user when everything is ok. In general less clicks are better, but you have to find a good  signal-to-noise ratio.
  • Empty state
  •  Partial state
  •  Error state (Kan later, error popups)
  •  Full state
  • Loading state (kan later, gewoon loader)
  • Disabled state

Related checklist categories

Visual design

Navigation  (structure/organisation, labeling, IA order of items, layout)

Flow! – a wireframe is only as good as the quality of the flow it belongs to e.g.



Form and error handling+feedback


Compatibility  (non-functional requirements incl. mobile)




Resolution (fixed, elastic, fluid, liquid)

Advertising (more page views)

Similar articles

Heuristics  (=extended checklists)


Maybe   (with related articles  browser!)

Short checklists


TO DO: Reduce this list and sort in order of most common issue