ChatGPT for UX Design: 7 of Our Favorite Prompts

The information volume about AI and design is already overwhelming right now. So, to help me break my own learning into logical categories, I'm always thinking about an intersection of AI and design into two main frames: *designing with AI* and  *designing for AI*. When I talk about designing for AI, what I'm talking about is a whole new world  of design challenges and opportunities

that we have to navigate when building products in the age of AI. AI interactions in our products require a new way of thinking. And in an article published by Jakob Nielsen, he announces AI as the first new UI paradigm in 60 years. What does this mean? In conventional systems based on command interactions, the user issues commands to the computer one at a time until they reach the desired result, if – hopefully – the system is user-friendly enough to allow people to figure out

what commands to issue at each step. The computer listens to our commands  and executes them, hopefully as instructed. In the world of the new AI systems, the user doesn't tell the computer what to do, but instead they tell it the *outcome they hope to achieve*. So, Jakob Nielsen calls this *intent-based outcome specification* and argues that, compared to traditional command-based interactions, this paradigm completely reverses the locus of control.

Where we once ran the machine,  now we let the machine run itself. An example would be creating images. Let's say we want to create a digital illustration of a mountain. In a traditional UI system, we'd probably open Photoshop and start adding one instruction on top of the other, draw a triangle, add fill, round corners, add texture, and so on. With AI systems, we go to image generators like Midjourney or DALL-e and instruct it on what kind of image we want to get through prompts: "Draw me an image of a mountain at sunset." And then the computer does the work for you.

So, if you think about it, we'll be designing for a new realm of experiences, completely new user expectations, mental models, and fundamentally different interactions. Many of the traditional products we use are adding AI capabilities. And this is a trend that we will see expand through our product companies. So, it's pretty likely that in the future most of us will have had some sort of experience designing for AI interactions in our roles.

And then, for the second framing, *designing with AI*. I want to start with an idea that has been quite viral on social platforms for the past year. AI won't replace you. A person using AI will. What this means is that AI by itself doesn't hold a power to replace us, mostly because it's infant technology and it holds multiple limitations, some of which are not resolvable in the foreseeable future. For one, it can't figure out what problems to solve yet. AI has trouble understanding context, and because we're still in the age of narrow AI

where AI tools can only do one type of task, it's very hard to solve complex problems with AI alone. It's true that research is being done in the space of collaborative intelligence where under the guidance of a governing AI different AI models work together to tackle more sophisticated tasks and solve complex problems. But right now AI is mostly a one-trick pony, so it can't possibly understand complex systems like a person's context. Their psychology, environment, background, needs, goals,

aspirations, relationships interpret all the connections and understand how they might make this person's life better. Only humans can understand humans deeply enough to really address the problems they struggle with. Then, design solutions require *multi-disciplinary efforts*. Any design solution requires systems thinking making connections between multiple fields and sciences. Understanding interface design, human psychology, information architecture,

visual principles, accessibility design, anthropology and sociology, business strategy, content strategy,  user research, and so on. AI systems can't handle this level of complexity in grasping landscapes and putting different perspectives and disciplines together. *AI also lacks empathy and a good  understanding of human psychology*. Also, its ability for creativity and imagination is subject to debate. For a long time, I've hated the term "empathy".

I felt it was overused to the point it lost  meaning, it became overly diluted. But I believe it's making a spectacular comeback in the age of AI because I personally can't think of a better word that captures what will essentially make  us different from computers forever. We have the capacity of imagining and attempting to even feel what the other person feels. Even though computers might mimic a conversational apparent empathy or compassion, computers will never really feel, regardless of how well they'll be able to emulate that.

Also, human creativity and imagination are quite special, even magical I would say. Even though AI can successfully simulate human creativity by putting together existing elements to create something new, in a similar fashion in which people do that, that human special spark comes from imagination: To be able to think of something new. And if you think about it, just looking at AI-generated art will sort of tell you it's been generated by AI.

It's pretty stereotypical; you get the feeling it all looks the same, like something we've seen before. AI still needs a lot of guidance, handholding, and gets lost outside its context. AI can easily go wrong and hallucinate. This is a real technical AI industry term. We've seen some funny and some very worrying examples, but the gist of it is that AI needs us to hold its metaphorical hand. It doesn't perform very well by itself. But even with all these limitations, designers who understand that AI is an  opportunity for an exoskeleton

that enhances and augments their natural capabilities will increase their chances of remaining competitive in a market where most of the work will be produced by human-AI collaboration. AI can already support us with making better decisions faster, reducing our cognitive load from having to process large volumes of data, spend time on more meaningful and creative work, kickstart our work projects, artifacts  faster, increase the accuracy of our efforts, and so much more.

In the end, there's probably not going to be much escape from AI changing the way we work; so, you might as well prepare to become the person that uses AI to remain competitive.

The stages of the UX process are  not singular in offering opportunities for enhancing our ways of working. We can also look into automating side process things such as productivity or collaboration. I would personally start with the parts that we're naturally not very good at or the ones we don't enjoy doing. Who  wouldn't be excited to get rid of some of the menial tasks?

So, here are some ideas for using AI  in our design work: Creating icons with Midjourney; generating presentations with tools such as Tome or Beautiful.AI; stock imagery with Midjourney, DALL-E, Stable Diffusion; color palettes with Chroma; writing documentation with Notion AI, writing with Grammarly, and many other options. The landscape of AI tools is rapidly changing. So many new capabilities pop up every week. The best best way to explore ways of optimizing your work is to go to

platforms like Futurepedia and see what's new, play around with the tools, learn and experiment on your own. I choose to set aside 2-3 hours  in my calendar every week, AI playground time, where I simply experiment as much as I can with whatever I stumble upon. It may be something worth trying.

You know, as human beings we have the strength of  visual reasoning to understand and perceive things visually, and it's just an incredible tool to bring  people together at actually a pretty low cost. If you think about what it takes  to perceive and understand a broad, rich journey, that's a *book*, right? And so, you have to find ways to articulate the customer journey

and contact with your company and product  in a way that's succinct and in a way that people can grasp whether they're a designer  or whether they have time to read a big book or not. So, it's a tool that is almost like  a democratization of information in a way. And so, it both spreads the information  and brings people together, and helps you make decisions and perceive things that  might otherwise not be known or understood.

In this presentation, we look at how user research fits into your design process and when to do different types of user studies. If you decide to invest time in doing user research, it's important that you time it so that you get as much out of your efforts as possible. Here, we look at when you should do different types of user research and how research fits into the different work processes.

Before you can decide when to do user research, you have to clarify *why* you're doing user research. You need different kinds of insights at different times in your design process. Let's have a look at the overall reasons for doing user research. You can do user research to ensure that you have a good understanding of your users; what their everyday life looks like; what motivates them, and so on. If you understand the people who use your product, you can make designs that are relevant for them. This type of research is typically *qualitative interviews and observations*.

You can also do tests of the user experience to ensure that your design has a high level of usability. Finally, you can evaluate on the impact of your design – for instance, on the number of customers or efficiency of work processes. As you can probably see, the different types of research fit into the design process in different ways. Let's start by looking at how each type of research fits into a simplified timeline for product development. Afterwards, we'll look into how user research fits into different types of development processes.

Research to ensure that your design is relevant to your users will typically be interviews and observations at the user's home or another relevant context. Since research to ensure that you create relevant products is meant to influence what type of product you will develop, most of this research takes place at the *start* of the development process, either *concurrently* with ideation work or *before* any concept work is done. You can also do research to validate your design direction, once you've developed some concept ideas

that you can show prospective users or during early product development. After release, you can do the same type of research to understand how customers are using your product, to explore if they need other features or offer opportunity scoping for your next project. And that, of course, leads you back to the beginning of your next product development process. Research to ensure that your designs are easy to use is mostly done as usability tests. It's important to start usability testing as early in the design or development process as possible

so that you have time to make changes to your design if the tests show that changing the design will benefit the product. If you use paper prototypes or similar materials, you can do early user testing before you have an interactive interface. User testing works well in an iterative process where you continually do user tests to ensure that your design is easy and pleasurable to use. Finally, research to measure the impact of your design mostly takes place *after* your product is released. The studies can then lead to new development and design changes.

If you're working on web-based products such as apps and web pages, it makes sense to keep evaluating on the user experience after your first release. One thing is a simplified timeline, but when you can do user research and how much research you can do really depends on what type of development process you work in. You can fit user research into most work processes depending on how ambitious you are. But it's easier in some work processes than in others. Let's take a look at what a work process that's optimized for user research looks like.

*User-centered design* is an overall term for work processes that place the needs and abilities of the user at the center of the development process. It's been described in different terms, but overall it's an iterative process where the first step is *user research* to ensure the relevance of the product. The second step is to *define* concepts based on user insights. The third step is *design and development*. And the fourth step is *user-testing the solution*. Ideally, this iterative process continues until evaluations show that the product is ready to be released.

After release, evaluations of the customer experience might lead to further development. By the way, design thinking is one of the most well-known user-centered work processes. As you can see, the steps involved in design thinking are almost identical to the overall steps of the user-centered design process. When you work in a user-centered process, user research is an integrated part of that process. But, in reality, many work processes are either not like that or deviate from the basic process in different ways.

So, how do you approach user research if you don't work in a clear-cut user-centered process? If research is not an integrated part of your work process and it's not up to you to change the way of working, you can still do user research, but it's up to you to decide when and how. So, let's look at some rules of thumb for deciding if, when and how to do user research. The sooner in your process you can do research, the bigger the impact of your research will be.

If you can do research before development starts, you can help ensure that you work on products that are relevant to your users. If you can do research early in development, you have more time to make changes to ensure great user experience before your product is released, and so on. Sometimes, you work in projects where you're not involved in all phases of the development. But you can still do smaller research projects that influence the part of the project you *are* working on. If you're a UX designer who's not involved in early concept development, it still makes a lot of sense to do *iterative user testing* of your designs.

If you don't have a process for how to handle research results, you should stick to research where you also have influence on any design changes that your research brings about. If you *are* involved in planning your development process, make sure that you schedule in some time to do user research. That way, you can be *proactive* with your research rather than reactive, so you don't have to scramble for resources when you suddenly need research to support your design decisions.

Sometimes, you don't have the resources to do all the user research you'd like to do. In that case, think about which type of research will have the *biggest impact* on your particular project and prioritize doing those studies. If you have influence over how you plan your development, iterative processes are almost always preferable when it comes to getting the most out of your user research. Iterative processes make you open to changing the end goal of your design based on the results of your user research.

In many projects, your time and resources to do user research are scarce. Luckily, you can do a lot with a little. You can, for instance, do user tests with paper prototypes rather than with fully interactive prototypes that require software programming. Just remember that the *validity* of your research is always the most important thing. So, if your time and resources for doing research are so limited that your results won't be sensible, it's better *not* to do any research. Best case = you'll waste your time and nothing comes from it.

Worst case = insights that don't really represent the user will impact important design decisions. Similarly, if you're working on a project that could benefit from user insights but you don't have the time or resources to make any design changes based on your research, you should save your research efforts for another time when they make more sense. So, what's the take-away? User research fits into the development process on all stages, depending on why you want to do user research. When you should do research, and what type of research you can do, depends on what your work process looks like.

If you work in a user-centered design process, user research is an integrated part of the process. If you *don't* work in a user-centered design process, it's up to you to make smart decisions about when and how to do research.

Ditte Hvas Mortensen: Thinking about questions, there's a certain sequence to how you best do it. So, maybe you could start by saying something about what the best way is to start an interview. Ann Blandford: For sure, the best way to start any interview is with opening questions that set people at ease, that assure them of what kinds of topics are going to be covered,

that give them a sense of what will be done with the data, though maybe that will be even before the interview starts, as I think about it. But it's about *setting somebody at ease*, about *helping to build rapport with them*. Obviously, each of us as an interviewer has our own personal style. And also every *interviewee* has their own personal style. And so, no two interviews are actually the same as each other.

I can't imagine ever running two almost identical interviews because they do so much depend on the participants – both the interviewers and the interviewees involved. But it is initially about setting somebody at ease, asking them comparatively innocuous questions – for example, what their role is in the organization if it's about a work system or their experiences of using a technology *like* the one that you're thinking about designing.

D.M.: So, it sounds like it's also pretty concrete questions. A.B.: Usually initial ones – it's best in my experience to make them reasonably concrete. One can move on to more abstract or more speculative questions later. Or, you know, questions that perhaps get at more sensitive feelings and values and emotions will come

later in a conversation when people have settled in and have started to feel comfortable in the situation, as opposed to, you know, starting with "So, how do you *feel about* _____?" – you know. That's not likely to set somebody at ease – if you kind of head straight into those things at the outset. And then, at the end, it's important to wrap up in a way that again leaves people feeling that they've said what

they want to say, that there aren't any topics that *they* thought were important as part of this interview, that they had an agenda, giving them a chance to articulate anything that you might have missed, and also giving them a sense of what's going to happen *afterwards*, you know: Are you going to give them a report back? Are you going to advise their managing director about new technology requirements?

What will be done with the data – what's the *value of the interview* for them? Some people really care about that; others perhaps less so. So, it's about being sensitive to what different people need. And in the middle – I mean, that's obviously the bulk of it – it's really about *planning it well ahead of time* so that you've made sure that you're covering all the topics that you're aiming to cover in

a rational and sensible order. As I've said already, people may sometimes answer and introduce topics that they've thought about already and answer future questions before you've even asked those questions. That requires you to be on your toes and think, "Oh yes, they've already answered that completely," or, "They've already *partly* answered that," and then, you know, picking up on what they've already said so that you're showing that you've been listening to them, and pursuing that topic a bit more later.

But it's about *making it flow as a natural conversation* as far as possible, while also *covering the topics that you want to cover*. So, it's important to get the structure so that it's a natural one that flows for most people – even if some people will run it differently. And part of checking that is about *piloting it* – you know – running through it with a friend or with somebody who at least should be able to *pretend* that they're a participant in that study first, to make sure that

you've got a coherent set of questions that are *comprehensible*, that are *using the user's language*, talking in terms that make sense to them and that they can engage with. So, you know, none of us gets interviews right the first time. It's usually worth trialing them out and going from there. D.M.: So, it sounds like you should try to follow the user's or the participant's

– if she brings something up earlier than you had expected, you just go along with it, or...? A.B.: That's my style, certainly, you know, because once somebody's in the flow if they're talking about things that you want to cover *anyway*, it just seems most natural, then, as a conversation to let them carry on on that line; and then, when they've finished, perhaps bring it back to make sure that you are covering everything that you wanted to cover

– because otherwise it starts to feel very disjointed and people may well forget the thing that they'd already half-started to say, and so you'll then have lost it forever. So, it's much easier if people can actually just carry on in the flow, as long as they're not going *wildly off-topic* for too long a time. And actually respecting participants can very often involve them going off-topic for some parts of it.

And you're gently trying to bring them back, and exactly how you do that probably depends on your interviewing style, actually. I personally probably let people run on a bit longer than perhaps some other interviewers would because I want to find an opportune moment to get people back on track. I think probably the worst one I had was – again, it was a little while back –

where somebody wanted to express a lot about the unions in their organization and was determined to tell me about industrial relations even though my focus was on *technology design*. They were seeing the introduction of new technology as being closely linked to other aspects of their relationship with management. And, of course, those weren't directly relevant to me.

But if I had just kept shutting them off, then I don't think they'd have talked properly about their attitudes to the technology, either; so, it was about respecting the other things that they felt that they wanted to say that were in *their* minds related, even though they weren't as directly relevant to the user interaction design – to me. So, they were less directly relevant to me. It might have taken me slightly longer to get all the information that I needed in that situation, than it would have done had they completely stuck to my script.

But on the other hand, it helped me to build rapport. I think it gave me better information. It certainly meant that I had a better relationship with the people I was interviewing in that setting.

If you're starting as a designer, you don't  need a lot of colors, just as with fonts. If you're thinking, 'Okay, I have 60 million colors in that little picker, so let's try to use all of them!' that's not really the case. What you really need is a *background color*, a *foreground color* and an *accent color*. And there are some rules that you  can then look up on your own later, like the *60-30-10 rule*, which is pretty useful. But, in general, what you need to really remember from this is that you need a *background color*,  so in my case it's going to be white.

Then you need a *text color*, which is going to be some sort of black or dark gray, and the *accent color for the important actions*. And one thing that you can actually tweak here is to have that darker color instead of being pure black, add a little bit of that accent color. So, in our case, the blue to it, so it's just going to look a little bit more connected to the blue and it's just going to look better together. So, that's just one way. And you need *three colors* really to pull off most designs.

And you can start adding colors once you  feel more comfortable with them. But when you're starting, really just the less colors the better because it's just much harder that way to screw it up. Two of the worst possible color combinations  are mixing red with either very saturated blue or very saturated green. And if you look at it more closely depending on the type of screen that you have, you'll see that on the place where they kind of mix together,

that little line becomes a little bit fuzzy. If you look at it a little bit longer, it starts to hurt your eyes in some cases on some screens because this contrast of those colors works really, really bad together. So, if you want to make a Christmas app, for example, there are better ways to do it, but *generally avoid those color combinations* and *always test your colors if they're clashing that way*. So, you can just place one on top of the other and see if that fuzzy line appears on them.

And that's one way to actually test it – you know – *by eye*, just looking at it. If it looks good, then it looks good.

Before showing you an end to an AI-powered design process. That still happens under human guidance, which is the key point in this conversation. Let's go quickly over how AI can help us. So for ones that can decrease cognitive load, aid decision making by processing large volumes of data, can help us automate repetitive tasks such as formatting images or resizing text.

It can help us by providing more insights into human behavior and usage patterns. Also, with creating prototypes or mockups, all kinds of visual assets, it can spot usability issues and so on. AI can help us at every step of the design process. Covering our blind spots, augmenting our thinking, making us more efficient if we use it correctly. Here's how an end to end design process augmented by AI may look like. But the key to reading this schema are how I prefer to look at it:

there's always a person orchestrating this. The future in which AI could generate a cohesive, coherent, reliable and relevant design process end to end is a very distant future for now, and there's an impetuous need for someone governing over this process, applying critical thinking and showing intentionality at every stage of the design process. Also, because AI shows multiple limitations

on each of the steps shown in the schema. Nielsen Norman Group published an article unpacking the limits that currently surround the use of AI in research. To understand the context of their analysis. You need to know that there are currently two type of AI powered research tools we currently see on the market: insight generators and collaborators. AI Insight generators. These tools summarize user research sessions based only on the transcripts.

Since they don't accept any kind of additional information (context, past research, background information about the product and users and so on), they can be highly problematic in how they generate and present those summaries. While there are some workarounds like uploading background information as session notes to be added to the analysis, it's not the right framing for the source and it's not going to reflect correctly in the analysis and generation. Humans would be much better at this. The scoping and systems

thinking required to understand the interpretation landscape AI collaborators. These work similar to insight generators, but they're slightly better because they accept some contextual information provided by the researcher. For instance, the researcher might show to the AI some human generated interpretation to train it. The tool can then recommend tags for the thematic analysis of the data in addition to session transcripts, collaborators can also analyze researchers notes

and then create themes and insights based on input from multiple sources. But even though they appear to be a bit better, they're still significantly limited and pose a lot of problems, if not used with the right mindset and caution. The limitations they've identified and expand on in detail are: most AI tools can't process visual input, and the biggest problem with that is no human or AI tool can analyze usability testing sessions by the transcript alone.

Usability testing is a method that inherently relies on observing how the user is interacting with the product. Participants often think-aloud describing what they're doing and thinking. Their words do provide valuable information. However, you should never analyze usability tests based only on what participants say. Transcript-only analysis misses important context in user tests because participants don't verbalize all their actions don't describe every element in the product. Not always have a clear understanding or mental model of the product.

So for now, Nielsen Norman's group recommendation is do not trust AI tools that claim to be able to analyze usability testing sessions by transcripts alone. Future tools able to process video visuals will be much more useful for this method. Another problem is the limited understanding of the context. This remains a major problem. AI insight generators don't yet accept the study goals or research question insights or tags from previous

rounds of research, background information about a product or the user groups, contextual information about each participant, new user versus existing user, the list of tasks or interview questions. There is also a problem with the lack of citation and validation, which raises multiple concerns and problems. The tools aren't able to differentiate between the researchers notes and the actual session transcript. A major ethical concern here. We must always clearly separate our own interpretation or assumptions from what the participants said or did.

Another problem with the lack of citation is that it makes verifying accuracy very difficult. AI systems can sometimes produce information that sounds very plausible, but is actually incorrect. Unstable performance and usability issues are another problem. None of the tools they tested had solid usability or performance. They reported outages, errors and unstable performance in general. And then there's the problem of bias. According to Reva Schwartz and her colleagues, AI systems and applications can involve biases

at three levels: systematic, statistical and computational and human biases. AI must be trained on data which can introduce systematic such as historical and institutional and statistical biases, like a dataset sampling that is unrepresentative enough. When people are using a AI-powered results in decision making they can bring in human biases like anchoring bias. So bias can creep into research efforts on multiple levels,

and these tools don't yet have the mechanisms in place to prevent that. I wanted to discuss the limitations reported in the article in detail, because I believe we can easily extrapolate and expand them beyond just research tools. Most of these problems will be observable on other types of AI companions in the design process. Biases in image generation, limitations in being offered context, other kinds of input limitations, not accepting files or images,

output vagueness, generic results, and so on. So I think that this is a necessary frame to keep in mind when interacting and designing with the help of AI. Tools are not very reliable yet and accurate. So take everything they produce with a grain of salt and apply critical thinking at all times.

Do you feel intimidated or overwhelmed by the speed at which AI is advancing and impacting our work as designers? Join me on a journey into the age of A.I. We’ll explore how A.I. is shaping the way we work and the future of product and UX design. You'll understand why A.I. is your partner; an opportunity to work better and smarter; what designing for A.I. products entails; how we can augment our design process with the help of A.I. and much more.

With the right framework, thinking and systems, A.I. can be a force for good. And as designers, we have an important role in making sure that this will happen. Learn how to advocate for good A.I. practices and become a voice for good by joining me on this course.