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

Read more: mail of 20/4/2018  (


  • Add a touch of technical feasibility sanity-checking for realism – dream all you like, but at some point. Unless your goal is blindly drive enthousiasm within team, with the risk of shattering the initial dreams later on.
  • Fake a prototype – whether clickable prototype or paper prototype (wizard of Oz technique), whatever works towards validating

Gathering feedback

November 26, 2013

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

Avoiding slow design

July 3, 2010

Keywords: speed, efficiency, effectiveness

Let’s be honest – it happens to some of us more than others: as a designer you’ve been asked to complete a design by some deadline which seems impossible to you. This could apply to any work, whether it’s developing a concept, creating a designs, a well-written spec or a good presentation.

What can slow designers down and what can you do to speed things up?

– First start high-level and touch all stones quickly

Personas with quotes (and business proposition value), user flow/sitemap, storyboards with scenarios, high-level user stories (in Excel or post-its), competitive research, blue sky sketching, design principles (!)…in the early stages you want to iterate fast over many of these methods. Eventually the vision will become clearer and you can focus more on detail design. If you get stuck, move on to another method.

For more, see my Steps of interaction design post

– Don’t be a perfectionist

Rest assured that there´s no perfect answer.

– Don’t get stuck in detail
You must Know the constraints. Work on what you can or know first.

Walk the information space (competitors, sitemap, features post-its for roadmap) and gather what you can, put it out there on the wall)

Your first wireframes should be really high-level, use blocks. Don’t sweat the copy, only use header titles. Use a fat marker and don’t stress the details. You could sketch one screen on one A4; or to save space, split up an A4 into 4 or 6 parts to describes a sequence of user actions belonging to eachother (for example, if Registration steps needs to be visualised, it can be one one page. Or if you have the space, use horizontal or vertical tracks (of similar coloured paper or post-its) for Registration steps alone). At this point the purpose might be to visualise a possible direction to get team feedback early on.

– Find the detail balance
Don´t worry too much about the detail. It doesn´t have to be perfect. Get all the elements on the page in rough form, starting with high-level ´boxes´. When you´ve added enough detail and the deadline is nearing, start rearranging things. Then align things so they look good enough to the eye. Finally give everything some breathing space, leave some white space but don´t waste too much time on getting things pixel perfect. Eventhough your IA is only communicating something functional, giving it some visual structure and aestetic appeal helps convince the audience that the proposed design or concept is easy to use.

– Focus on the end-result, work on the essential 

Which pages really need be fleshed out? Spending more time on making the front page look and work  great may be better than having many dismal pages.

– Don’t get stuck in problems

While working on your design you may find an edge case that you feel will need more attention, sooner or later. Don’t give it your full attention just yet. Chances are, if it’s a conceptual presentation you are giving, it can be solved during detail design. Some problems solve themselves while working on other parts (relates to: deelproblemen). On the other hand, you might feel it’s a real biggy, some innovative products need some competitive/inspiration research in their most challenging or complex areas. However, you might discover

If it’s a core functionality that sticks out like a sore thumb, you might need to ‘go back to the drawing board’ and explore a different interaction approach.

– Distractions and concentration
Isolate yourself from distractions. Hide in another room. Put on headphones (I prefer instrumental or classical music that doesn´t contain words). Increase your concentration (get enough sleep, exercise and eat healthily). Create a serene working environment. (though a messy environment can make you more creative)

– Be honest
Be concious about when you are distracting yourself. Work towards your goal, and be cautious of diversions. For example, don´t delay because you like working out ´this little puzzle here´or like to get ´this little thing here´perfect because you personally prefer working on them.

– Rapid design
Don´t reinvent the wheel. There´s many sites or products out there which have done this before or something similar. Perhaps you could borrow their design and wireframe it.
Start with sketching. Don´t waste time with the tools (Axure, Photoshop, etc) until your certain about your design.

– Get help

Split the work, unless the briefing/training and communication required will take more time than actually doing it yourself. Where is the efficiency cut-off? And if you delegate, what quality and effort can you expect from the other(s)?

– Take a break!
Coffee anyone? You will still need some breaks to get your creative juices flowing and zoom out into the higher detail. Sleep is also important as it lets your subconcious work for you!
Take some distance. The more you look at a problem, the harder it will seem. Take a walk.

– Finally, say ´no´ more often – but nicely.
When the boss asks you to make the impossible happen, you have to manage his expectations on time. What does he need it for? Who is the audience? For example, will the design be thrown in as just one of many slides in his conceptual presentation, then don´t try to get it perfect. Chances are you don´t have to bog down into the detail, but just communicate the general idea. Get the objectives straight. If it still seems impossible, say so. Make it clear that with the time given, it won´t be a finished design but good enough to communicate the general functionality. Say what you will be able to do with with the given time. Here are some other tips to just say no under time pressure and other priorities. If time and budget are fixed, there is usually a trade-off between quality and quantity

Other thoughts:

  • Avoid interuptions. E-mails, phone calls, etc are unwelcome distractions. Don’t reply to them immediate
  • Finish what you started (when interupted). If somebody invades your space demanding your attention, show you are deep into finishing a sentence.
  • Work in burst. Work 45min shifts, take 10min breaks. Breaks help you see things from a distance, in perspective, from high-level.
  • Work intensively, twice a day. Research shows better violinists don’t necessary work harder or longer. In fact, they have two periods in the day where they are on full, intense concentration  (morning and sometime in the afternoon?). The rest of the day, they take it more easy. This way they get better at what they’re good at. Of course, if it’s not practice you are after but finishing something that requires relatively few brain-power, you might want to make an exception (?)
  • Stop early. Research shows more practice does not always make perfect. Quiting early, enough sleep is what differentiates good from expert musicians.
  • Be end-result driven. It’s all about goals. Constantly ask yourself why you are doing what you are doing and how does it help you achieve the end-result. If it doesn’t, take a step back and try a different strategy.
  • Fix your decisions. Constantly changing your mind about how to approach something, means you are constantly applying this new means over and over. Decide on a system, structure or format first. Work with it for all instances. Else you will find yourself with the next point:
  • Always have a finished product. Deadlines are tight. Your work might never be finished or perfect, but at least make it is written and structured in such a way that  you can hand it over for somebody to read or work on at any time.
  • Do one thing at a time. Research shows multi-tasking is not efficient.
  • Mind like water. Have a GTD system for clearing your mind. If you interupt yourself  with things not related to the task at hand (“I still have to do ….” or “I must remember to…”) or another project  (“I could use this solution for project x”). All this is held in your mental working RAM, waiting for action. Write it down somewhere where you know you will look at it  (@inbox). Getting this like that off your mind will clear it  and improve your creative potential.

Tool tips:

  •  Content and layout first, Style after. Whether you’re working in Powerpoint or Axure, add the content first. Styling, structure, alignment, font sizes, colours – all these things are better left until later. The reason is that more than often you want to add or change something, but you only realise later. Then you have to re-apply and adjust all the style again. Another reason is that the appropriate style or format sometimes only becomes apparent later.
  • Be creative away from the computer first. Whether you’re considering a good structure/format for a presentation, mindmapping/brainstorming, or have some wireframing to do: always first start on paper, post-its (for ppt)  or whiteboard, or even draw in sand. Creative sparks often happen elsewhere, not behind the computer. Computers limit exploration.
  • Be systematic, work in a structured manner. This won’t bother your creativity.


Fortune cookies

Neem genoegen uit wat je al hebt en gebruik dat gewoon!
“It’s good enough”
En klusje doorstrepen, hatseflats! En je bent er vanaf, hoe heerlijk is dat?!

Further reading
Making design decisions

Articulating design decisions

May 21, 2010

I just came back from the Amsterdam UX meetup  where Tom Greever presented his new book Articulating design decisions. Tom explained some of the challenges you as designer face when selling your design ideas to stakeholders. He also mentioned some solutions on how to properly deal with feedback when you don’t agree with it, often diplomatically and respectfully.

Tom’s talk motivated me to polish up and publicise this post, finally. Thanks!

Disclaimer: this post is a combination of my (old) notes, thoughts and references.


In this article I talk about about presenting your designs and how to get buy-in and convince your boss or client about a certain design.

Ultimately, stakeholders are interested in how to lift conversions (and other KPIs). There is countless data, research and evidence out there, but which will persuade your boss or client?

This article is relevant to any part of the process:

– analysis and research
– consulting
– presenting designs and recommendations
– designing deliverables (powerpoint, e-mail attachments, or other non-personal format)
– answering questions / giving advice or recommendations
– writing functional specificatons

How did you make your design decisions?

To quote Anne Holland’s words, most sites are designed by:

  • Owner’s gut
  • Pre-formatted templates
  • Copying competitors
  • ‘Best practices’
  • Testing

The question is, which research and best practice, if any, can safely be re-applied to your particular project? And to which degree of confidence?

Evidence-based design

Here are some common research methods to back up your design decisions:

– Usability lab test
Guerilla usability test
– Hallway testing
– Think-Aloud test
– Remote usability test
– Mobile usabilty test

– Eyetracking
– Card sorting
– Icon matching test

– Expert review (objective!)
– Usability heuristics

– A/B test
– Google Analytics
– MVT test

There is something to be said for all of these methods. In general, research can offer some insight or influence direction. However, it is not always welcomely received by all. The data from a lot of research is multi-interpretable, but not multi-applicable. Outcomes change with time and different cultures/countries. Statistics can be easily manipulated, as Edward Tufte has shown us. Hence we must resort to other means of persuasion.

Scale of persuasion

There are many methods and tactics to convince others about a design. What did you base your design decisions on? On the axis of true certainty, when it comes to communicating design decisions, where are you? Let’s rank some common methods/tactics from low to high confidence, where the highest confidence is “the plain truth”, this is what such a scale might look like:

1. Designer’s intuition (using cognitive walkthrough, from gut feel or experience) or genius design
2. Patterns (Styleguides, User Interface pattern library, iOS/Android UI guidelines)
3. Conventions (like competitor audits)
4. Best Practice or competitor audits or top sites (Often heard the boss/VP/CEO saying:”.. that’s how Apple/Facebook/Google do it!”)
5. Confidence. A lot of hard-headed talking (without pausing) makes it sounds you´re sure of yourself, which helps convince others about your ideas.
6. Research (slideshare by doctors or professors, advice from good-looking or well-rated blogs, or hard numbers from any official looking body of knowledge)
7. MVT and A/B split tests results and case studies

It’s number 5 we’re not all comfortable with. Luckily, good leaders know it’s not just about appearances or your voice that determines your success. Though it may initially help in convincing others of your design decisions, you should back up your design decision with true certainty.

Which of the above will resonate most with your boss?

Lastly, your tools and methods presentation need to be good. See my  about ‘Convincing stakeholders’

Communicating design decisions

Sketching, storytelling, critiquing, presenting and facilitating. These are five indispensable skills any interaction designer (that deals with internal or clients discussions) should have. They are most useful in live discussions, brainstorming and workshops.

At other times the communication is not live. It´s by e-mail. Or if the above is not directly available or people are fully booked during business hours to listen to your design. Always ask yourself first if live presentating is better than sending deliverables. I sometimes like to use below methods as pre-work to explore design options and also to anticipate audience questions along the way.

You can either explore design alternatives, or get feedback using one of the following options. Let´s look at each option more closely. Decisions can be based on ….
– Assumptions  – are my favourite and an important tool for freelancers or agency employees. Instead of bombarding the client with questions, make assumptions if you can’t quickly get in touch with real users for quality feedback. With the limited time you have, make some quick assumptions and deliver a design as quick as possible. Back it up with your own ‘assumed personas’ and do your own rapid user research (for example by skimming online discussion and support forums). Show that you did this if necessary.
 – Assertions –  Providing a rationale statement by adding the business reasoning and arguments for the design. For example: “This button will be orange. Rationale: Research has shown that orange buttons convert best.”
– Options – Explore if’s, if NOT’s, show alternatives but never more than 2 to 4. Give stakeholders a choice and ask questions to understand their arguments and context.
– Generalisations – audit, conventions, competitor analysis

– Questions – see Q&A below

Dealing with indecision

When requirements aren´t clear or complete, it is useful to communicate your decisions in the form of recommendations by providing or extending the requirements shows your confidence. If this is the case you can either ask for clarity, or if you have the feeling the requirements author doesn´t really know either, just start designing. It is  common in many projects that design feeds requirements through a process of iteration . The last thing you want is to slow your design or getting the blame for delayed projects.

Indecisions and unknows are not desirable – they can hamper your design. In functional specifications, they could be indicated as:
– Open questions – a structured list (sometimes Excel) of outstanding issues that address unanswered design requirements. They can be complemented with:
– Questions (shows most uncertainty. Can be Q/A self-interview style, so your assumed answers are already there, making it easier for your reviewer to confirm). Sometimes open-ended questions work well, especially for sensitive issues (for example when asking about business values: “Our business gets most complaints about …”. See also the Business Assumptions sheet in Lean UX book [link])
– “TBD” or TBC – when clearly marked (e.g. in red) and indicated within a document or wireframe, may work if limited in amount. Downside is that may indicate the unwilligness/uncertainty of the designer to provide answers, even if in reality there are ´holes´not covered in the requirements specs and need to be answered with the help of a product owner.
– “Input needed from product owner” – like TBD, but clearly pushes the responsibility to the product owner. If you must resort to such measures, try to get the input beforehand.
– “(name of product owner)”, – shows reviewers (people likely to be involved or read the docs/see the design) clearly who is responsible and who needs to do the action to get things moving forwards and make work happen. For each action there is a person’s name and a clear divide of accountability.
– bunch of backlog post-its – it’s good to review these once in a while. Some issues are good to park, decisions to post-pone, and some solve themselves along the way while working on other stuff.

The goal is to avoid any indecision at all. Organise a workshop early on to get a group decision if needed. Making ideas happen is often about getting a decision out there, rather than making the best decision. Keep in mind, ideas are flexible and not set in stone.

From Concepting phase to Elaboration phase..

Ask questions – Q&A style

Another way to get decisions done is to ask yourself your own Q&A in an inverview style, as if you were interviewing a stakeholder. This shows a lot of confidence and is useful if you are picking up early signs of non-support.

For example:
Q: Why is this widget required?
A: Many users will be asked the same questions during check-out. The widget communicates and radiates importance, but not urgency, and is perceived as optional for those who know about its function.
Q: Will users use the widget?
A: The widget is prominent and dominant in visual design, and the most noticeable element on screen. The copy is inviting.

In some companies the UX designer is expected to chase the developers/product owners to get the answers. The culture then is more of a “If it ain´t clear, ask for clarity” approach. In other companies, especially those with less control or transparency or unclear processes, it is common for designers to postpone projects or getting designs done by ´blaming´the product owner for not providing enough answers (on time) or due to meager requirements specifications.

In many design projects, it can´t be avoided. Requirements feed design, but also vice-versa.

Some tips:
– Share. Honesty and frequent, good communication is the key.
– Involve. Regular sessions to communicate design decisions and blockers (learning from SCRUM).
– Ask for help. A project manager can help to chase people and keep things moving on. Get a single point of contact from the developers team.

The art of persuasion

What convinces your stakeholders?

  • Styleguides like those of Apple or Yale or others e.g.
  • “Providing as much factual data as possible and 2) asking very direct and unemotional questions. For example, questions might be “How will the impact of this feature/interaction be measured?” or “Do you have data or studies to show that this would lead to the improvement you’re expecting?” Not all solutions can be data driven but if you have a set of key studies and research you are better off. “
  • “best practice … that starts with something like this: “There are no right or wrong ways to design a website or application. Over the last decade a lot of research and observation has been done to determine best practice. As the web is a fast evolving environment the research subject is a moving target and thus research tends to be very time and device specific.”
  • Present with confidence using psychology and sales person tactics
  • Speak their language – if they are used to data, costs and numbers (and graphs),  use them as your convincing tools. Measure the effect (%) of your designs versus old designs if needed.

Verbal confidence

Zurb’s article talks about Designers at the table:

  • Talk lower. If her pitch is naturally on the higher side (like mine), the designer can practice talking at a lower one. She’ll instantly sound more confident, like magic.
  • Talk slower. It’s easy trip on words when the brain can’t keep up with the mouth. Slow down, pause between points. It’ll make the designer sound more thoughtful.
  • Don’t end statements on high note, like a question. It’s a super common mistake, and an easy one to curb by paying attention to the voice.
  • Don’t fill time by repeating a point twice. Instead of building confidence, it actually does the opposite. Repeating a statement makes the designer sound unsure, like she’s trying to convince everyone, including herself. It’s another mistake we often see (and personally struggle with). It takes a conscious effort to break this habit.

Breaking convention

You have this new idea, your own insight or innovative pattern that is trending in your design circles. Perhaps it’s placing the breadcrumb trail at the bottom of the page, or perhaps it’s even more zany. Yet, it breaks most convention. Should the initial design stay with conventions, or can you introduce this zany idea? After you have convinced yourself, can you convince your stakeholders?

Read my post about ‘Consistency’

Further reading

The post was initially entitled “Communicating design with confidence” but I have renamed it to match Tom’s book. Hope you don’t mind, Tom 😉

Though I have not read Tom’s book myself yet, I think Tom’s book is probably a very worthwhile read for anyone frequently dealing with external clients. Get the e-book or paperback at Oreilly’s online store.

Related articles?

QOC (“Questions, Options, and Criteria: Elements of Design Space Analysis”‘)

Steps of interaction design and UX

January 19, 2010

* denotes required steps. Other step are often skipped or optional.

Definition and requirements

Define the website goals and project scope. It is not always the ID-ers job to come up with requirements, but they are often refined when gathering inspiration [link to private post] and during design.

  • Define the vision
  • Define the challenges/problems
  • SWOT analysis

Define the target audience

  • persona’s
  • contextual scenario’s

Business and user goals

  • interview and observe users
  • talk to product managers and marketing department
  • study competitors

Technological constraints

  • available programmers and their proficiency (skills and knowledge)
  • compatibility  (screen resolution, bandwidth)
  • supported functions (existing reusable components
  • innovation constraints (culture)

Application/website constraints (re-usable templates, fixed navigation elements) – these become your design constraints. Agree on which page templates (columns), high-level that you will base your designs on (rules/principles/constraints/scope).

Also consider deadline, time-to-market (feature cost-benefit).

Gather facts and goals about the website. Question to ask your client before any user research (and design project)

0. Strategy and concept

There are 3 levels within interaction design: [The in-mates are running the asylum, Alan Cooper]
1. Concept design
2. Behavioural design
3. Interface design

A good over of the overall levels outside interaction design, see JJG’s elements of user experience. (img)

Define user + device scope.

1. High-level overview (structure and flow)

First, start with content:

  • Which pages should there be?
  • On each page, which content should belong there? User flow.

Don’t be afraid to divert from the page and boxes model. For example, a one-page navigation/experience could be worth exploring.

List the high-level view, graphically or textually. With the birds-eye view, prioritise each element so you know which one needs most emphasis. Use the

Tools for brainstorming and sketching

Tools: Pen and paper, beer & back of a napkin 😉 , walk/shower/jog, whiteboards, brown paper, mindmapping tools, comics and storyboards, different visual views (Adaptive path), stories & scenarios, proto-personas
Online collaborative whiteboards: see other post

Tools for structuring

Sitemaps and diagrams,  Flowcharts,  notepad/Excel (indented), mindmaps, rough sketch (blocks) ,post-its

Page layout options

Layout options means exploring: Lightboxes, tabs, filters, columns, carrousels, rollover tooltips, accordions, grids, (mega) dropd-downs, etc

2. Coarse design

After agreeing on the high-level principles with your client, now it’s time to dive into more detail, explore the design space.

Work by iterative design

Get inspiration, note/collect good examples and research best practice and patterns, Google images  (e.g. “toggle UI”), high-level blocks, design, get feedback, design, ask bypassers, discuss, design, get feedback.

Wireframing and prototyping
Tools: prototyping tools are (from easy to use to more expert knowledge required): Balsamiq, Omnigraffle, Visio, Axure, Fireworks, DHTML, Flash, Visual Studio
Wireframing                   Interactive prototypes

Axure                   Y                                                   Y

Links to other pages with overview of ID tools.


The earlier the better. Paper prototyping or clickable prototypes.

3. Detail design

Support the visual designer and overview usability. When to do graphical design? Agile vs waterfall.


Tools: Excel, Word
Methods: Use cases
Also known as:

Define all use cases and defaults. Be sure, in later stages, to include edge-cases (randgevallen).

4. QA and functional testing

Visual design comes at play after, but often at parallel with, interaction design.

Testing. Though not always an interaction designer’s job, testing the builds and implementations for bugs, functional malfunctions and interaction design.


Remember to always…

  • Iterate

Exploring design space

1. Invetorise the known, cluster the known, prioritise (order)
2. Explore UI possibilities using the patterns at hand (patterns: accordion, tabs, show more links, anchors, etc)
3. Check if it’s scalable (future-proof) and check for edge cases (amounts, visual limits)
4. Check other constraints, boundaries, limitations. Min/max and average in terms of data, content, image dimensions, labels
5. Simplify the UI @

This is not linear! Do a bit on every step.

UX team of one

As a UX team of one I experienced good results following these steps (iteratively!):
– Vision statements (write down assumptions derived from business needs, and stakeholder quotes)
– Brainstorm your proto-persona (get at least 3) or at least a basic list of user needs (assumed)
– Competitive research (evaluate direct competitors, pros and cons of their interface. what do their users say/need on forum)
– Inspiration research (get a feel for potential solutions by checking how do others solve this problem)
– Features (A list of potential requirements structured Excel columns or Word indents is often good enough.)
– Sketches (screens and elements in their alternative 6-up approaches, patterns, format variants). Going back and forth from competitors screenshots to your sketches.
– Flows and storyboards  (walk through the possible experience as a user)
– Sitemap, use flow  (get down what you know)
– Design principles  (these act as guidelines and constraints, and as input to features/roadmap)

Only after this get into detail design, unless failing fast is an option.

Remember to contribute to team roadmap, critisize features value, offer technical solutions potentials (even at technology level, like scripts, APIs, or data sources), visualise the process & experience for them.

– User Stories  (Agile)

Annotations on your sketches, wireframes and competitive/inspiration evaluations can drive the features/stories/requirements/roadmap.

More (start at Structure)

See also my posts about basic, laws and principles of effective interaction design for the web.  Process, method toolbox and internal influences/roles

Methods and toolkit, toolbox:   (extended)  (UX evaluation methods)

Keyword: UCD process, user-centered design process, workflow, design work-flow, agency work flow

Giving constructive design feedback and critique

August 18, 2009

Social skills. There are times when you have to tell a website owner or another designer what’s bad about their design or site. In face-to-face discussions the way you communicate for optimal effect is crucial.

Roles: Presenter, Facilitator, Recorder

The importance of critique


How to give critique

  • Respect the design owner. Start with some positive feedback.
    affirmative criticism. Receiving a compliment delivers an endorphin rush. The presenter also hears what shouldn’t change or go away in future renditions of the work. In many ways, this is as important than knowing what needs changing. It forms a good design “root system” of that everything else can grow from.”
  • Just ask yourself these questions during your critique: What did I enjoy about this design and why? What concerns me about this design and why? What does this design remind me of and why?
  • Talk about the bigger picture/rationale. Instead of saying, “While I think those flyout menus are slick, I recommend you nuke them and put the links in the center of the page,” the critic might ask, “What alternatives did you consider for the flyout menus?”. While, in any project, practical constraints often win out, discussing the higher level concepts help the design owner (and other team members) make better decisions going forward.
  • Knowing that one day they’d also be a chosen one, the kids would be very careful about how they worded their “bads.” They’d try to be very constructive, often forming a question, such as, “Did you intend for me to see that was my card before you flipped it over? ” This gives the presenter a chance to think about what they intended to happen, versus what actually happened. 
  • “Have you considered…” is a great way to start an important criticism, since it gives the design owner a chance to say, “I did, but I chose this direction because…” Now, the team can talk about the bigger issues behind the rationale instead of nit-picking the design details.

“This is undesired behaviour.” or “not recommended’

“This harms or does not benefit findability.”

Other possible topics for this post: how to gather and structure critique.

Inspirational sources: (Dealing with criticism) (ID and Strategy)

Visual design review tool   Intersections are focus points for the eye. Others: contrast, blur, 50%, mirror, contrast, grayscale.

Similar posts (still to read & evaluate