Google Sprints – what I learned

November 7, 2017

The Google Design Sprint is a co-creation, collaborative process. In the experience I gained in these sprints, it helped me see the whole holistic problem space with potential solutions end-to-end.

From now on, I will push myself more through rapid iterations. As a UX team of one, I will more frequently assume and test:

  • personas
  • business goals
  • available data & content priorities
  • prototype

This opened up early findings and designs to the world of stakeholders and know which domain experts to contact in the future.

  • Reduces disbelief, increases empathy for decisions
  • Test early assumptions and turn them into insights
  • Set priorities for design and identify epics

UX strategy – drivers and priorities

November 7, 2017

According to designer Nick Babich:

“The best products do 2 things well: features and details. Features are what draw people to your product. Details are what keep them there.”

I would argue that one missing point here is good Visual Design that catches their eye’s interest. This is where aesthetics, branding and promotional material (brochures, offline) play an important role. As Don Norman puts it: beautiful products are perceived to be more usable. Especially in competitive markets, the details like resonating typography and imagery help your product stand out from the crowd.

What about after you have caught their eye? What are the main influences or determinants (drivers) of success for that step in terms of product design and other factors? The user’s is a part emotional and part rational decision journey.

UX strategy model

Above I’ve used the AIDA model as a starting point. Translating and thinking it through: what does every step in AIDA mean for your product? This model is draft work in progress.

Speak to the eye, mind and heart to win your audiences’ smiles.

Enablers of prolonged product use

Once you have drawn the users in, even after they have purchased or converted, how to retain them and make them loyal? To reduce the gap to make them proceed to the next phase, remove all barriers and obstacles along the way.

  • Ease of access  (how easy is it to obtain the product?)
  • Ease of use (does low usability hamper the use is the product)
  • Aesthetics (Reduced clutter, for example, to see the forest for the trees)
  • Security/privacy issues
  • Personalisation  – examples: make content relevant to each user; dashboards; so that I don’t have to re-configure and do lots of manual work every time I use the product
  • Learning barriers (with onboarding techniques for example)
  • Provide ‘light’ versions with added advanced functionality as needed
  • Pricing (survive the trial, get the benefit of paying/upgrading)

Further reading

Trust related issues –

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?)


Pattern: inline labels

September 27, 2016

In reaction to Baymard’s post ‘avoiding inline labels in mobile forms‘ there is a recent pattern I have been seeing, at least have seen so far on 2 desktop sites:


Clicking an empty form moves the inline label to above textfield, and resizes label

The patterns ignores Baymard recommendations, but still works for me. Still have to test if & how they did it on mobile. The only issue I can imagine is if the textfield is on top of the viewport. Otherwise shouldn’t seem a problem CSS wise.


Update: Nowadays this is standard Material design  (see

Zoom effect

March 10, 2016


Make a Magnifying Glass Effect in PowerPoint

  1. Duplicate the layer
  2. Crop as a circle
  3. Add Bevel with height 18




How To Create A Simple Zoomed Effect On Screenshots In GIMP



keywords: portfolio

Powerpoint productivity tips

August 25, 2015

Keyboard shortcuts

Alt, H, G, K Send to Back – Send the selected object behind all other objects. – Home > Drawing > Arrange > Send to Back
Alt, H, G, R Bring to Front
Alt, H, G, F Bring Forward

Alt, H, H Distribute Horizontal

……. Crop





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.