How to test designs, but not overpromise

Last week I used AI to help me write the text, but in the end it completely changed my tone of voice and I wasn’t happy with it.

I’ll carry on writing content myself so that I can then use my texts as source material for the AI.

Now, onto my last week’s conundrum.

I am working on a project where we are developing a case management system. The interesting thing is that not only will the system be new, but also some of the users’ processes.

One of the things I’ve been talking about lately with my colleagues is that we spend too much time investigating current user needs. Users don’t know how to predict something for the future. They don’t know how they will be using a product and what their needs will be at that point.

Our job should also become anticipating needs.

The question my team is grappling with at the moment is how to test prototypes with users when they won’t know what needs they will have in the future.

I am eering on the side of caution when it comes to the designs that we show users. On a previous project we had showed too much. Users liked the proposed designs. That might sound like a great thing, but it ended up causing pain and friction:

• users liked the proposed designs and wanted to have them in the final product

• the designs seemed feasible at the time, but later on dev discovered that they would be difficult to implement

• there were delays and users were growing increasingly frustrated

• my team was also becoming frustrated because it was hard to manage user expectations considering the technical complexity we were not aware of

• it was all painful for everyone

So I don’t want to repeat the same scenario.

It’s tricky to strike the right balance between showing not enough and just enough to start a conversation. Right now it feels like we are trying to show more than we should be.

This is where careful prioritisation will be even more important - differentiating the must haves from nice to haves will have a significant impact on development time.

I also don’t think that time is on our side. I worked on a previous CRM system for over 8 months and user stories were getting increasingly complex. I also tested them all as functionality was getting developed and it took ages only to fix some of the bugs.

We’ll see what we end up with and what are the designs that we show to the users, but I will mainly be dedicating my time to another part of the service which is the front-end for the public. We need to keep developers busy.