What is effective documentation for design – dev handover?

Text documents for requirements have long gone from most companies, but identifying the ideal level of detail, format and location for the source of truth depends on many factors varies from company to company and team to team.

At worst, the latest mockup sits in a designer’s set of files in various chunks, making handover patchy and hugely dependent on one person’s availability.

  • Digital whiteboards are fab, but can become unwieldy when hi-fidelity specification is required.
  • Physical printouts and notes on walls are a great discussion tool, but not for remote or hybrid working.
  • User journeys lack the UI so are too vague for development or require matching up additional items.
  • Interactive prototypes require you know where to click, and by that point you might have well just created it in code anyway.

I think I’ve seen and tried every combination possible. I have shied away from documentation on account of it sounding waterfall and not lean enough. After all, there is no document in the world that has enough detail to be complete “enough” and that makes it too big an investment of time. The product needs the investment, not the documentation, so what approach works?

Mostly the choice has been organic based on the people involved and the software they use. The latest trends as well as the skills of the team are also huge influences. But if you want to be strategic about documentation, imho there are a couple of important factors that should inform your choice.

Product maturity

If the product doesn’t exist yet, napkins and notes are good enough. The product is small and it’s clear what it does. The coders are commenting and vision documents from stakeholders combine into the start up documentation set. A great front ender will mock up an idea in code quicker than on paper or design software, facilitating discussion and testing.

As the product stabilises, capturing some reference to design and business decisions and pivots is more useful than it may seem at the time, especially for a company that is starting to grow.
There is also a risk in having this knowledge in one person’s head. People move on then you’ve got an issue.
If you have remote workers, a wiki page of some sort can be useful for quick comments and screenshots. But don’t get lost in difficult to use wiki formats and protocols; it’s better people can jot down their comments when they make an update. This makes the decisions more visible. Whether they were the right ones is a different topic. Jira boards are considered documentation enough by some, but can be impenetrable to non-dev folk. Consider the team, location, skills and needs.

If the product is mature and has people (both users and workers) needing to consult what it does now to know if it’s working correctly, you need some kind of reliable documentation. Ideally Jira tickets, knowledge base and forum, as well as the product update page and website all tell the same story.
However, employees and stakeholders need to know one place to look for the different types of artefact (design mock ups, product decisions or the reasons why it’s so great). Notes and napkins at this point are a nightmare because they are not collaborative enough. However, if you have a channel, blog, wiki or wall, you can use that same napkin, just remember to photo and comment it.

If a legacy redesign is underway, capturing what used to happen and what’s changed is important, but communicating it across the company and user base is more so.

Team skills and size

Who is hands on in your product design team makes a difference. If everyone codes, clearly you won’t have the need for more design mockups, commenting and screenshots for customer support may work well enough.

If the team is more mixed, the need for a common accessible product design snapshot is more important.

Mockup map

A map is quicker to put together than a fully interactive prototype, and it’s definitely a clearer discussion tool. Whether you consider yourself to be a visual thinker (I do), or whether you believe all that to be nonsense, for me looking at the same picture is priceless. “I’m glad we all agree” from Jeff Patton captures this beautifully.

This applies to when we’re ready to share with the wider team, but it actually really helps the designers spot gaps and obstacles, and us all to rethink different aspects when we can look at the same thing together.

Ensure the happy path is communicated, variants are then easily understood.

Note I didn’t say it was quick to create a map, it’s just quicker than a fully interactive prototype. It still needs the thinking and iterations. Depending on what stage the design is at, they can be sticky notes and rough sketches, cobbled together with borrowed screenshots and videos. It will resemble a vision board more than a UI design in the early stage and a hi-fidelity flow with final art boards in the latter.
This process and output will outline the user journey and add in questions about tech feasibility in one place.

The important part is to make very clear which is the basic flow, the one that provides the outcome for the user and the organisation. Without that, additional editing and nice to have options can overshadow the core flow and the main point gets lost or diluted down.

If you can get to a map that’s clear and well-defined, an interactive prototype or the product itself is then quicker to build because you have all the pieces and most of the questions answered.

Software choices

Figma has been a game-changer for us, but not in the way I had anticipated when I subscribed our budding product design team.
I had used it before for simple wires and interactive mockups, and expected it to be mainly useful for testing, but where it has really come into its own has been with the relatively new Figjam boards, which we use to map out the flows.

Happily, there are many software alternatives out there and new ones emerging. Whichever tool you find, a giant digital canvas is great for remote collaboration. What I didn’t expect was it to fill this gap so well in terms of lean documentation.

Miro has always been a pleasure to use, but our mockups are in Figma, so Figjam means one product covers our needs. Zeplin is also appreciated by developers for picking up designs. It has recently opened up Flows, but we have not found them as useful yet as our Figma and Figjam combo.

Your story

What software or practice has revolutionised your lean handover practices?

When should I do user research? Once, twice, …always.

Transformation comes from automating habits into practices repeated little and often. This is the approach I prefer to take for user research.

User research takes many forms from testing interfaces, observing users use your product, to interviewing them about all and everything. When, what and how you should do research really comes down to the pace of your team.

Continuous discovery means you never stop looking to inform your thinking about your users and their pain points.

However, recruiting and maintaining the quality and cadence of the sessions with participants can be time-consuming. So, is it worth it?


Once you have the processes in place to keep the users coming, you can up-level to make sure you’re getting the right kind of users at the right time.

If you have users of specific kinds, or you know who have provided quality, constructive, thoughtful feedback on specific aspects of your product, perhaps in conversation, surveys or via your help centre, these are the ones to book time with. Linking these interviews to coincide with the same focus of your work is actually a huge timesaver. 🕰️ ❤️

Managing your user pool or recruitment flow requires some effort to put the systems in place and then much less effort for the upkeep. Here are few things to consider:

  • If you notice one group is harder to reach than others, it’s a sign to tweak your process, source from elsewhere or perhaps bump your incentive up. 💶 💵
  • Research ops is a whole framework that looks at the infrastructure needed to get your UX practices in place and has a helpful community you can reach out to. 👐
  • Occasionally users will not be who or what you’re expecting at all. This can be ok as it will challenge your thinking. However, screen participants so you get those of interest. Have they used your product? Are they the right kind of person in terms of habits, location, mindset or lifestyle? 🧍🧍

Research sessions can be inspiring, uplifting, challenging, 🤸 basically any kind of weird and wonderful.
Let me know what you come up against or love about setting up or running user research.
Whatever you do, keep taking steps towards making it happen!

Photo by UX Indonesia on Unsplash

How to start your idea for a mobile app

Podcast notes – Wireframe the journey
The steps to take to create your mobile app Listen to the audio here

  1. Identify the starting point and the desired end point
    e.g. if someone wants to create a lovely meal, are they starting from an ingredient or a recipe? Do they want to end up with an understanding of how to make the meal, or serve it and have it on the table?
  2. Avoid starting from components as this might restrict you. If you have existing screens or styles, feel free to use these though as it might save you time later.
  3. Map the journey one step per screen or post it. The user can only focus on one thing, so what is it? Is this step important? Is it in the right sequence?
  4. Layout and components can then start to enter the picture. You don’t want to reinvent the wheel, now you have your journey, make use of other existing components or UI standards. A customer comes to you with prior web experience, so harness it!
  5. Find inspiration if things don’t seem to work or fit, look at what else is done elsewhere and what is the result? Is it good or bad and why? Check the spacing, movement
  6. Think about vertical arrangement of contents, which side pages enter from and disappear to. How much information sits on a page comfortably?
  7. Stick to black and white and one other colour for emphasis and to emphasise key points or calls to action.

    wireframe black and white sketches on paper
  8. Revisit your initial goals: can the user get from the start to the finish? Is it a good outcome?

Tools: any will do! Figma and Miro, or Mural are nice.

From the other side of the Jira board

20 years in UX, 6 months as product owner.

One product, one team, right?
That’s the theory.

UX and dev are not always marching to the beat of the same drum whether down to the team set up, culture or methodology. I have not yet come across the perfect solution to marrying sprints with UX, no matter how lean the UX or outcome focused the dev approach.

I know the pain of coming up with a ‘great’ UX solution: end-to-end, easy to use, covers all the pain points, nails all the details, harmoniously blends with existing flows…

And then the shock of seeing only pieces of it implemented. The famous first phase. The frustration of dev “tickets” missing the whole picture.

Mr Potato Head without the potato body and no mouth.

So now I’m in the other camp. No longer just the UX user-advocate role, but the one who has to say which is the most valuable “piece” because the whole thing would take just way too long and so by the time it was done, nobody would care.

Time, money and value. Maximum value, minimum everything else. Using the leanest approaches I can to try and cover the most ground.

Fundamentally, the question has changed. Before, if it was what would make the best outcome in the most frictionless way possible, now it’s, perhaps, what will make the most impact in the shortest time possible.

It has the feeling of downsizing, like in the movies. Moving from a mansion to a caravan. More austere, some tough decisions, generally not as romantic as it sounds. There’s potential for it to be somewhat liberating, and it is certainly a good exercise in focus. Cut out all the noise and see what is left, and hope it’s still understood and fun as Mr Potato head, and not just as sad and scary like a few body parts.

Terrified of design crits? You’re not alone.

You’ve got your brief, you think you understand the problem, your plan is to go away and quickly mock up some screens.

Do you:
A. Have a clear idea and end up producing a tonne of output that takes you so far down a certain path that it’s hard to backtrack. Input from the team, users or stakeholders then either means patching up a solution or the soul-destroying realisation of it not being fit for purpose, but there’s not really additional time to start again. Result: panic.

Traffic cone prevents people walking on broken pavement

B. You go away thinking it’s clear, but nothing seems to materialise beyond a login screen. Looking at a blank screen, you tweak a few bits and pieces, but don’t really move forward. Colleagues ask for an update and your only viable option seems to be able to delay and go offline promising the world for a day or two later.
Result: panic.
2 days later, you’re more or less in the same spot, but now you’re starting to consider going into hiding because now you’ve got the added time pressure.
Person hiding and peaking through a hole

Take a breath 🙂 Stop suffering. 🤗
You don’t need to create perfect screens alone. Hi-res screens that look great and work perfectly will come, but first you need to start talking through it, bouncing ideas around, sketching to think and discuss, not to present handover deliverables.

Top tips

  • Share your work little and often with a key team member
  • Time box sketching by targeting specific design problems
  • Get inspired by looking elsewhere
  • Take a short break, maybe do some exercise
  • Design a research session involving your work and users

Sharing little and often is the quickest way out of any rut.

Fearful of a design critique?

  • Take control and ask specific questions re what you need to know
  • Don’t hide your design work striving for a “finished” deliverable.
  • You cannot solve design decisions by yourself if the problem connects to users, stakeholders and development options
  • Share little and often as part of your process
  • Get comfortable with “scruffy” sketches; they’re impossible to understand alone, but talking people through them works

Have you heard of achievement journals?
If it’s a good idea reflect after each project, extract a summary and materials to talk through what you have created, it’s also great to keep a note of what you’ve achieved. Celebrate what you’ve learned and the road travelled.
High five

Why the humble main menu is important to UX

A main menu is not very interesting to look at artistically-speaking, indeed it probably shouldn’t be. It is, however, a really useful set of clues for a user as to the content contained behind it.

The top-level menu labels should appear to be a set and:

  • be descriptive of all the contents it leads to (providing good “information scent”).
  • be unambiguous
  • clearly different to the others in the same menu
  • of the same level of granularity as the other menu labels

You might have heard of the rule of 7+/- 2. A lot of people cast aspersions about that number, but I think it’s still reasonably stable in terms of a rule of thumb for the recommended number of menu items.
Basically, if you have got a menu that has more than 7 menu items, it shouldn’t grow much greater than 9, because it gets too much to read through, and if it’s a lot smaller than 5, perhaps the menu is not needed or is too deep and so not well-organised.
If you have just two items, you can use something like tabs or a different UI element, depending on what your content is.
If you’re a large store and you have two categories, then 7+/-2 is perhaps not going to be such a useful ballpark figure for you to think about in regards to types of item.

Ideally, all of the top menu labels will have roughly the same number of options taking the user deeper. For example, they could all have about seven suboptions, but if one of them had three, and two of them had fifteen, it would not be well-balanced.
However, each case is different.

In summary, the top-level menu is a quick overview for a user. It’s not very snazzy, but it is really important to have a good structure and one that communicates what your site is about.

For a little more on this topic and to hear about card sorting, have a listen to my latest podcast episode.


UX tips for start-ups

My latest article for the small business and start-up community, Know your customers and how to talk to them is now available on the Enterprise Nation website.

In this post, the second of a series of four, I cover:

  1. The biggest, and probably the most common mistake, I see when people engage with their customers,
  2. Why you should look at what people do and not what people say, and last but not least;
  3. Why the user’s context is so important.

If this is something you can relate to, or you are struggling to get started, do get in touch. You can drop me a line by clicking on the envelope above, or book a time to talk here.

A simple way to start user research

I wanted people to not fear user research as being too difficult, mysterious or time-consuming and present, in a nutshell, the practical steps necessary to go from start to finish. Of course, there are more details you can add in, but the important thing is to start somewhere!

I’ve listed 6 simple steps:

  1. Define the question
  2. Find participants
  3. Organise the materials
  4. The structure of a user research interview or test
  5. Tips for running the session
  6. What to do with the information you gather

This is aimed at small teams or microbusinesses; people who are wearing many hats and are not able to recruit a specialist at this time.

My aim is that people (businesses, product owners, developers) engage with people (potential or actual customers) to gain an understanding of their needs and so better products are built!

You can listen to my podcast episode on this topic at anchor.fm/liz-parham.

The slides showing the 6 steps to setting up a simple user research session.

Show notes follow

In this very first episode of the Let’s UX Podcast I hope to help you get your user research efforts off the ground and improve your user experience just one step at a time.
This one is for you if you’ve thought about research but haven’t quite taken the first step. I will take you through 6 simple steps to get you started today.

It’s brilliant that you’re here! Getting more people involved in the process of design and development will produce better products, and everybody’s going to be so much happier, let’s face it!

So let’s get stuck in.

If it’s a bit of a mystery as to when and why you might start doing user research, I think there are three main reasons:

  • The first: understand customers better. Their lives, their language, where they would use your solution, other solutions they’ve tried… all of this information will help you make design decisions further along because you won’t be projecting your own preferences and experiences and you’ll be thinking more about real customers.
  • Another could be to test out your website or your app. Don’t really know how well it’s performing? The best way is to put it in front of people and observe them use it.
  • Another reason could be to explore new ideas, new concepts and to iterate on those ideas with them and get feedback.

And that’s the only way to really evolve and iterate on your design before it’s developed, saving money down the line by getting clear: are these good solutions? How well would they work?

Listen to this episode here at anchor.fm/liz-parham.


I love helping technology work well for people and for businesses.

I am currently creating this website, which is why it’s a little spartan right now. …And as soon as I’ve figured out why the links are red, I’ll fix it, promise!

Take a look here for links to my UX programme and more.

Meanwhile, you can find my podcast below