Tell me about it! I am joining this party a bit late (kind of 4 years late?) but, anyway…
I am working on my MSc thesis (with a Computer Science BSc) trying to compile a list of requirements based on a Goal-Directed process. I interviewed some people, made some personas from those (and some other data) and now I’m trying to get the requirements for the product (a mobile application)

It took me a long time, and it wasn’t until my supervisor finally told me, that I didn’t have to answer the question “how is the user going to add a widget? a button? telepathy? a link? how? how? how? HOW AM I SUPPOSED TO TO KNOW IT??!?”, but just mention that “there has to be a way to add a widget”, as you say.

Cheers!

I too am wondering how traditional specs can be improved with regard to specs and UI design. First off by ‘specs’ I assume you mean ‘Functional Specifications’, where I work we have 3 specs – Business, Functional/User, and Technical.

For our current project we have a Functional Spec which incorporates the user interface design, now well over 200 pages. It is impossible to maintain and noone wants to read it – its too big, takes too long to print etc. There is always a rush to finish the UI as the Functional Spec has to be ‘signed-off’ by stakeholders.

We have done a hifi wireframe in HTML, and everytime there’s a change to it, the spec must reflect the changes. The spec also has screenshots of all screens, and when we encounter problems with the wireframe at coding time, noone wants to make a big change as the specs has to change also. The people who create the wireframe are not the application coders, therefore the application coders ‘disown’ the html and expect it to be accessible, validate, and work in all browsers. One of the disadvantages of hifi html wireframes/prototypes I feel.

Anyhow, I digress. I would like to see a separation of functional spec and UI design. Stakeholders can sign off on the functional spec, develop the UI as a separate process. This means that the scope business rules, etc are complete and signed off. It also means that the stakeholders cannot hijack the design process – “I want a flashing logo or I’m not signing off”, or when you want to change something in the UI you dont need a stakeholder meeting.

I imagine that the wireframe is the de facto spec, the thing that everybody refers to day to day.

Your situation (which I obviously sympathize with) sounds like asking a building architect to represent all the information in a large blueprint in a series of 8 1/2 x 11 pages without using pictures. “Section 3.2.4: Bedroom. The bedroom provides facilities for sleeping, reading, and television watching if the optional television module is installed. The south wall includes two windows, which may be opened and closed by operating the latches (Part #3321, Anderson Windows) and moving the interior panes up and down…”

I’m not sure what you mean by the application coders “disowning” the prototype code. They expect it to be better quality?

The ‘developers’ in this case are the middle tier guys. They are too busy integrating the app with other enterprise systems and databases to care about the html. They assume the wireframe is a finished product, which it isnt. My experience with customers is that they too see a hifi wireframe and think its the finished product – but thats another article

I guess the question I am asking is “can we create more usable specs by separating functionality from design?” In my experience the functional specs require signoff from stakeholders, and the application is then developed and tested against these specs. The interface design should be a flexible and iterative process involving end users, designers, and implementing best practices – not tied up with stakeholders who want to dictate UI design.

It’s hard to get people to separate functionality in the abstract from the realization of it in the user interface. What you really need is a separation of problems from solutions. Logically, you need the solutions to flow from the problems, but technology products don’t always work that way.

Often, functional specs say things like, “User needs an Add Widget button” when in fact the user doesn’t need a button but just the capability to add widgets. Sometimes, clients don’t mind or notice that I don’t take premature UI design literally. Unfortunately, most people don’t have the design vocabulary to describe what they want without suggesting something concrete. Engineers especially (I am one so I can say this) have trouble stopping with a problem statement, and proceed right into the solution. So we end up with “Customer needs Add Widget Button” instead of “customer needs a way to add widgets,” or even better, “Customer’s current widget index card file makes it difficult to share widget information like part numbers with the Phoenix office.”

Once the concrete solution has been proposed, the UI designer has to explain why a change is needed, and so you end up arguing about the Add Widget button instead of what the best way to get widget part numbers to Phoenix. I find it helps if you can appear prescient by telling people they’re going to have this reaction well before any particular issue comes up, and that the UI might end up being quite different from just the sum of the functions suggested.

Worth a read if one of your main audiences is coders.

Yes, I agree with you on everything you said.
Well, up to certain point.

Your view of traditional spec might be different for certain organization. I worked in a large company, where it took many years to get all the groups in a company to agree on a process. So, to introduce nontraditional spec as part of the process will take very long time and buy in.

But if it’s a new company or even small startup, it might be easier. That’s just an assumption.

I don’t like very strict process, but some companies require development teams to follow very strict engineering process even if it’s not the best (sometimes to meet some standards).

In seperate note, I also wanted to comment on who should write the UI specs. Writing specs long time. You could hire somebody full time to write UI specs all day, but lot of companies won’t invest in something like that. So, we the UI desigers and engineers end up writing it. But lot of UI designers have very little training in writing good specs, especially for softwares. It’s hard to spend time writing “ideal” specs while doing user research and interaction design.

I really think writing effective spec should be done by technical products managers or program managers. I know in microsoft, this is how it’s done.
Yes, there are lot of bad things about microsoft, but their software engineering process is lot better than most companies out there.

So for some of us who do not have program managers with UI developmenet/design skills,
it just means more work for us.

By the way, if anybody knows of any good cheap software for producing and managing UI specs, let me know.

The problem with writing specs and why people find them hard to maintain is that they try to write them in word. Using a word processor is an impossibly difficult way to maintain something as complex as a spec.

There is also a widespread misconception (mainly web driven) that wireframes constitute a spec. IMHO they are not. Helpful, but not a spec.

To write a good spec You need to know functionally what you want to achieve in the product. You have to map these requirements to how you want to achieve them. This involves back end, front end, big end and all sorts of other ends but the main thing is to get to an end-to-end understanding of the product and why you are doing what you are doing.

People draw up wireframes too soon without thinking about the business processes and rules first. If you cannot clearly follow a line of thought from a wireframe justifiably back to a requirement then who said it should be there? Not the customer, that’s for sure.

Another thing that drives me nuts is that people don’t use the right tools. Forget Visio, forget HTML, forget word and forget Photoshop. These are all rubbish for doing a wireframe or lo-fi design.

Why? Because they do not capture information well. On a screen design you need to capture visual placement but also rules, definitions of screen areas, field names, button functions, interactions, etc… People do this by drawing something up in a drawing package then trying to assign information to it by writing a document to go with it. For example, to be any use to a developer, a design should indicate which fields from the database each field on the screen represents. Now watch your designers head explode when you give them a data model to decipher.

Even if you manage to finish one version of this complex task it will never get kept up to date as the wireframes change – it’s just too much effort.

The best tools to use for writing your spec and initial UI design are CASE tools such as System Architect, Enterprise Architect, RUP, etc…

Put your project requirements into such a tool and your spec will write itself when you press the export button. Draw your wireframes in a CASE tool and as you change the wireframes, UI elements, requirements, use cases etc so does your documentation. It really is that simple.

[Something worth noting is that your customer may not fully understand your spec and what the implications of it are. This means there should be some translation of your spec into a form they can understand. This is where a "usable spec" can help and I have drawn things up in many ways in the past to get people to understand. Whatever it takes...:]

Ji Kim said above:

“But lot of UI designers have very little training in writing good specs, especially for softwares.”

I agree with that entirely. The spec writing process can be hijacked by a range of people who are not skilled or trained in business process analysis, systems analysis, technical writing or systems design (architecture). The depth of knowledge is not there to understand anything except the superficial issues around wireframes.

Having said all this, I don’t believe in strict processes either. Use the analysis and design tools by figuring out what you want to get out of them – not by following a methodology just for the sake of it. Just make sure you justify your approach.

I also firmly believe in the 80 / 20 rule. It rules. Simply put, the 80/20 rule states that the relationship between input and output is rarely, if ever, balanced. When applied to work it means that approximately 20 percent of your efforts produce 80 percent of the results. Learning to recognize and then focus on that 20 percent is the key to making the most effective use of your time.

So, design 80% of your system/site/application then build something. The first iteration of design is often the most productive yet projects rarely achieve full iteration even once without prejudice. Yet you will spend 80% more time trying to figure out that elusive 20% extra detail. Iterate through a design and prototype just once and those elusive details will likely fall into your lap.

Going to a building analogy – used to be a surveyor in a previous life – an architect will design a building to an incredible level of detail that would make most software teams shudder. They can tell you how many nuts and bolts are required to build a 50 storey skyscraper and how many litres of paint for the stairwells.

Why? Because they are using the right tools and not re-inventing the wheel. CAD tools, technical drawing and standard processes mean they know exactly what to do to get the thing built. An architect also has an enormous level of technical understanding – he doesn’t just draw pictures. Again, this is how they can plan in such detail.

All of this rambling boils down to saying that a spec is requirements and functionality driven and a wireframe is an implementation task that is more than just pictures.

Cheers,

Screen

and then

All the elements in the screen in a table called ui elements or something like that.

If someone knows where it is please let me know the url. Thanks