Web industry and its labels
Posted by Silvia | Filed under Career
When my family, friends or colleagues ask me about my profession it is hard to make them understand what my role exactly is and even what I actually do for living. I’ve received diverse labels since I’m in this field. Webdesigner, webmaster, user interface designer, interaction designer, CSS specialist, user experience designer, functional designer, information architect, information analyst, requirements gatherer, usability expert… The list goes on. How do I name my job? Do I have a label? Already for some time I’ve been looking for a clear answer.
In the IT field there are a lot of questioning regarding the boundaries, responsibilities, tools and deliverables for the design and development of applications and websites. What are the roles needed in a team to make a professional website or application from beginning to end? What is the set of skills/tool you should have in your pocket? There are so many terms nowadays.
In the middle of another attempt to clarify this matter, I found a schema that looks reasonable. I see myself into those three first blocks: webdesign, interactiondesign and interactiondevelopment. One thing is sure: Web development is not for me.
For my frustration (or not) I don’t have a label! Why should I have one? And you? Where do you fit into?
Tags: Career, Interaction Design, job title, roles, web, web development, webdesign
Are Use Cases the death of good UI Design?
Posted by Silvia | Filed under Design tools, Interaction Design
It is an editorial from almost 10 years ago, but maybe still actual.
From uidesign.net - View Article
UML 1.3 has been released. The 3 Amigos ( Booch, Jacobson and Rumbaugh ) are each publishing a book about UML. Many others have already been published and many more will follow. Jacobson’s Objectory Methodology has been renamed and repackaged as Rational Unified Process.
UML is complex! Of that there can be no doubt. Because it comes with the hitherto impossible dream of “unification” of design methods, the software community are eager to take it up. Professionals are afraid of being swept away by the adoption of this new technique and they are afraid of looking silly in front of their colleagues. How many of you right now have a half thumbed book on UML lying on your desk?
I find this hysteria worrying. For greater reason than I find any hysteria worrying. The problem with UML is that it comes as part of Rational Unified Process. RUP aka Objectory is particularly important to UI Design and Development because it is about Controllers and Controllers are about behaviour.
In his 1994 book, Ivar Jacobson proposed the Use Case as the specification for the controller in an MVC architecture. This leads to the adoption of Model, View and Controller Stereotype definitions in UML. The controller in theory is a state machine middle layer which controls the program flow between Views and Model (persistence) layer. The Use Case describes the User interaction with the system. It has even been advocated that the Use Case is the System Test plan, already written.
Since, the original papers and book, there have been many proposals on how to write a Use Case, when to write it and what to write it about. Even in recent material such as UML Distilled by Martin Fowler, the water is muddied by a vague definition and indeed two proposals as to what a Use Case is, and when to write one.
The basic problem with all of this is that a Use Case takes the form of a narrative which reads: the user does this; the system does that; the user does something else; the system does the next thing. More specifically this may read like; the User selects an item from the list; the system highlights the item and opens a dialog of item attributes. This is undoubtedly a system design. In fact it is more than that, it is an Interaction Design. Interaction Design is the job of a User Interface Designer.
So who I hear you ask do Jacobson et al propose should write these Use Cases - these Interaction Specifications to use another term? Well there are two schools of thought on that one also. First off - the Business Analyst or Domain Analyst. It is the job of a Business Analyst to write the specification. They should understand what the system must do functionally. What the business needs the system to perform. The second school believe that a requirement should not detail such things and Use Cases should be written by programmers at the Design Stage of a development project. Uh huh!
So in conclusion the User Interaction is developed by either the Business Analysts or the Programmers. Neither sets of people have necessarily any training in User Interaction, so there is little hope that they will make a good job of it.
There is a further complication with this process. Lets imagine that the project does have a User Interface Designer or a number of programmers with interface design skill. If they should modify the interaction at development time so that it is more usable, then two things happen. The design which is built will no longer match the design as specified which means that the Use Case can no longer be used for testing. Secondly, tracking what has actually been built in terms of functionality and where it can be found, against the original functionality which is buried inside the Use Cases, becomes next to impossible.
The reality is simple. You cannot have good User Interface Interaction Design and Usability together with Use Cases. It would only work if the Interaction Design and Prototype Usability Testing were done up front before any Use Cases were written. In a real project this would never happen. Besides, if the Use Cases are the requirement document, how can it be possible to design the User Interaction without a requirement. If the requirement is an Interaction Design then why employ an Interaction Designer?
The adoption of Rational Unified Process in its complete form is likely to set the development of good User Interface Design back by perhaps 20 years.
Tags: Design tools, Interaction Design, RUP, use cases