Steve Blank - What would it look like? Wireframes as a basis.
Before you bombard your customer with suggestions and possibly overwhelm him, I would always suggest that you first seek the conversation. Listen to your client and ask questions.
Today we would like to think about how you can present something visual to a customer and thus also determine what should come out in the end. This is indeed a very important approach. Remember our last article where we talked about physical products and creating a "tangible" prototype? Basically, the procedure is the same, except that you don't have any material costs here, because you can design the things on the screen. Let's go through the process with a website.
Talk to customer
Before you bombard your customer with suggestions and possibly overwhelm him, I would always suggest that you first seek the conversation. Listen to your client and ask questions. Is there already a website? Is there analysis data for it? Is there a corporate design? Should there be special functions, a web shop or an area where only customers can log in?
The first thing you need to do in a customer talk is to get a feel for which direction it should go.
Back in the office, the information is evaluated and a first real wireframe with functions is set up with the design team. This does not cost so much at first and can be used later in development. With the wireframe and the limited functions, another customer discussion can take place. There the wishes, problems and requirements from the initial meeting will be taken up again and discussed on the basis of the built template. The customer then has the chance to use the prototype to develop a visual feel for the arrangement and the respective process and can thus give targeted feedback.
This step is enormously important and can save a lot of time and money, an initial investment that is well worth it.
The first beta
Once everything has been discussed, the built wireframes can be extended with the customer's wishes and prepared for the development team. There you can develop until a first usable beta for the customer is available. Often the mistake is made that a customer is granted access too late or too early. Customers often do not understand the development stages and come up with change requests or complaints, which often prove to be redundant in the later beta. If you're attentive during the initial phase of the customer meeting and the prototype, this will rarely happen.
With the beta, we can then discuss the project live with the customer and record their feedback and reactions. It usually makes sense for the customer to be looked after by us during this appointment so that he understands what is going on and how. He "learns" from us to use his product and is prepared for discussions with his own team.
As a rule, several users will have different reactions and wishes. We have already discussed the topic in other articles. We record the feedback and then sort it according to relevance and urgency. We then go through this list with our customer and decide which of them really make sense.
This process is suitable for almost all software projects and is basically decided only by the complexity and merging of individual departments or requirements. If we define the right strategy right from the start, confusion and frustration rarely occur.
This article is written by our CEO, Bernd Korz. With his experience as an entrepreneur, he shares his vision about the lessons provided by Steve Blank. Join us every week for a new article on Steve Blank’s lectures.
More information on Steve Blank:
- alugha Videos
- Google Search
- Amazon Books
- Twitter Steve Blank
- Twitter Bernd Korz