Hi,

I've been purely  UI and UX designer before, but now i do mainly business analyst assignments with UX twist. Neither BA or programmer will know how to do usable UI without studying the field a bit, but it's not too difficult.

To answer you original question, I must answer as a true consultant... It depends :-)

There has been a few good suggestions and comments. Firstly, it's true that you should separate overall functionality from UI, but only to certain extent. I'll try to demonstrate it by example. Ok, if you are selecting a COTS package it's essential to have business, user and functional requirements separated from UI. This is because you are selecting package based on capability, not because of it's UI. You do have to make evaluation of UI and include only feasible options to your shortlist (i.e. those which don't look overly complicated wiht gazillion modal windows etc). You can and should have requirements about UI and it's usability. "1. Customer information entry must be presented in one screen. 2. It must support using without mouse. 3. Entering new customer should not take more than xx seconds."

When making requirements about UI, you must think about how each UI requirements supports high-level requirements. Good UI can be very effective way to increase work efficiency!

When building custom applications or products or services that will be sold to customers, it's not so clear that you should develop functional requirements, use cases and UIs separately. Example: Functional requirements for iphone and non-touch UI phone would be pretty much similar to certain point. Only the exceptional UI of iPhone was the business requirements that delivered a) best user experience b) differentiation in markets. But there's a catch here. Be aware what is you projects' goal. If you are creating a some generic business application, there probably is no justification to build a totally customized UI. Those would require that it affects strategical, business and mission critical functions of organization in question. 

One special thing about UI is that it brings together and validates

• Information model (what data, values must be available at any given time? How they will relate to each other in UI and ER model?)
• Functional requirement (does UI allow user to complete task that fills a business goal?)
• Some non-functional requirements (how effective UI is? is it usable by color blind? etc)
• One more related thing to understand is, that some requirements /UI features will bring any value only if set of other requirements will be also done in same release. E.g. no point in implementing map-UI, if none of location features are present in same release. So, UI can help in scoping, not only scope creep...

One good piece of advice was to think about these things in generic tems/ flow to identify what information needs to be present at the same time. Depending on organization, you can be facing a situation where none of the customers understands data model and can't validate the structure for you. But when you show them UI sketches, they will know what they want!

What this means in practice? When application is bespoke i can create fast mockup screens based on initial requirements. When client is happy with screens and flow based on above criteria, i can break down the mockups into generic requirements. 

You can attach the UI skteches in your requirements documents with comment, "Illustration of one possible way to satisfy requirement BR123". This gives potential vendors much better understanding of client expectations about functionality. For example, compare following requirements.

1. User can enter text and format it before publishing (no UI image)

2. User can enter text and format it before publishing with following functionality: Bold; Italic; Font type; font size; ... (etc for total of about 60 formatting options, no UI image)

3. User can enter text and format it before publishing with UI offering capability similar to UI123 (attached image UI123 of web-based wysiwyg editing component)

Which of the above requirements is least unambiguous? For which of them it would be easiest to give an accurate work estimate? Which of them would be most meaningful as a backlog item for scrum team and would need least amount of non-reusable documentation? 

Then again, for COTS package selection, you should have it as a written requirements - "Solution has a wysiwyg editor for formatting forum posts."

I am not sure if this helped or confused more.

Petteri

Hi, Kimbo

No, that is not the case, i didn't mean to do that. Good you raised the point. You still need to do functional analysis to identify necessary use cases and to identify goals etc. In era of AJAX interfaces and business using complex applications, some functionality is easier to discuss through prototypes. On the other hand, some functionality is nearly impossible to specify through prototypes.

So, to enforce what Kimbo wrote and to clarify my original message

-Analyse needed functionality to ensure you have covered it all (for example, important security related functionality will not be visible in UI so using only prototype can cause you to miss these)
-Prototypes and Use Cases must go hand in hand.
-Some "use cases" are easier to work through UI prototypes once you have agreed on user goal (one picture does say more than 1000 words). You still need to support prototype with written specification which refers to prototype or screens
-Relationship between use case and screen is not 1-to-1, it's often 1-to-many and sometimes even many-to-many. I.e. one screen or screen component (=compartment)  can be used by many use cases. Say...hmmm... map interface, selection patterns etc. Only their content varies, not how it's presented. (that relates to style guides and UI standards)

In most cases UI prototype gives better idea of targeted approach and quality of functionality and helps in getting more accurate quotes or estimates. Same use case with quick and dirty form-entry interface without client side error handling and interaction is much easier to implement than UI with AJAX, browser-side value checking etc. Difference can be 5 fold. 

Some of our internal tests have shown that prototyping can decrease change requests during implementation by 70 - 80%. We have been using use cases for very long time and this has been a huge improvement. Approach requires a good team with BA/ Analyst, UI design and usability skills. I do recommend that you take an open-minded look at using ui prototypes to replace fully-dressed, detailed use cases in later design phase. It probably will save you time, ensure better quality and facilitates understanding between different parties.

As all models, it is just an aid, not the only way.

Petteri