UX design specification format

Question

We have a legacy (desktop based, developed since 90's) product that is quite successful despite having some UX and UI flaws. Recently we have decided to redesign that as SPA.

In the process we would like to start by attempting to get the UX better (if not right) by having that designed by some UX professional who is out of the company so that he has fresh, unbiased point of view and look at the product. This will be our first experience with proper UX design(er).

I believe we do know the domain, we do know what the users want/would appreciate, what operations are most common and require quick access etc.

As it is now, we have the specification (sort of) ready in the form of an "essay" or "letter" describing functional, non functional requirements, operations etc. in free language.

We have deliberately decided not to do any wireframes or detailed hints at what the system should look or behave like to not influence the designer by ours in-the-box minds. Well apart from the suggestion that it should have Material design, minor contradiction here ;) We have also decided to not include what current product looks like.

We see that it should look as a modern app, with the design similar to GMail or Google Docs:

• standard toolbar on the top
• master/detail views
• some notifications coming in
• some bookmarks

...simply nothing extraordinary these days but still would like to get that designed properly.

We expect that the designer will come back with further questions and we will be happy to provide answers. But our goal really is to let him/her do the job with as open mind as possible.

Is this naive/laughable approach?

Will the designer appreciate the freedom given? Or would s/he rather get very much detailed description with hints at what is our vision in terms of UX/UI and just fix it?

Should we take some more standard, structured approach to the specification document? If so, any hints on the structure?

Secondly, if this does not get closed as too broad or downvoted, what would be the price range, if anyone can estimate based on the facts above? (ducks)

Thanks in advance.

Answer 1

You have done a great job in documenting the functionalities and providing more space to the designer. I believe your approach is great for creating a good product. At the same time, I would consider sharing the existing screens and explaining the designer on the most used functionalities/sections and the existing pain points. Along with the user interview, the existing screens would help the designers to understand the application better!

Pricing depends on various factors. Check this link to get an overview of UX pricing: https://uxmastery.com/how-to-estimate-a-ux-project.

Answer 2

I think that it’s completely ok to have requirements written in a document. Actually it’s great that you don't want to influence designer by presenting your own wireframes. In fact it’s his job to ask a lot of questions and come up with ideas.

But to make your cooperation smooth I would share every insight with designer. Everything you know will be beneficial for him. Access to the current product can be very helpful in understanding context, users' needs and most importantly - your business. Designer can also run an expert review on your product in order to verify weak and strong points of current solution.

Very important is to understand what UX Designer can do for you and not to fall into a trap of “popular misconceptions about UX Design”. So to better understand what is a role of UX Designer and how you can use his specific set of skills for your business, I recommend a great article - “How UX Designer can bring profit to you business”.

As for estimations and pricing, product estimations are always very specific. High standard designer/agency will ask a lot of questions, dig deeper into problem before full project estimation. It’s crucial to know what will be exactly needed, how much time project can take, what you expect etc.

Answer 3

To not show the current design to the designer can be a good approach, but I would say that it depends on the complexity of the product/service. It is often very hard to explain the functionality and requirements of an existing product without actually showing it. Basically, you would waste a lot of your and the designers time (and money). A skilled designer should be able to look at an existing product without being affected by it.