2

I know that some website are applications, but not all websites are applications (albeit maybe just a brochure viewing site)

Is there an in depth dummy use case for a brochure type site which would be beneficial to use.

When it comes to a corporate front facing website for example I suffer from feature blindness, although for an actual database driven application (for example a purchase order system) I feel within my element.

Is there any resources that can help me view "brochure" sites in the same light than I do with a pro bono database driven applications.

Joseph Le Brech
  • 6,541
  • 11
  • 49
  • 84
  • Would a "brochure viewing site" not be limited to merely 2 use cases? "see a list of brocures c.q. possible pages to view" , "view a brochure/page" ? Just my thought... – Bazzz Mar 21 '11 at 10:09
  • that's exactly what i was thinking, that's why i find it very difficult to convert someones explanation of a website written in word over an excel spreadsheet that someone needs converting to a crm or bespoke app for example. – Joseph Le Brech Mar 21 '11 at 10:36
  • Maybe you should mock-up your 2 use cases and discuss them with the client, and see what kind of feed-back they give. I think it is of no use trying to add cases that are not within the clients cognitive understanding of how the website should work. You suffering from feature-blindness is not so bad if the client doesn't want those features. – Bazzz Mar 21 '11 at 11:47

2 Answers2

1

This is really useful thread. I have always battled with use cases for brochure sites, despite totally espousing the use of UML... I often feel caught between UX agency outputs & trying to ensure the whole Requirements Spec ties together, especially when agencies tend not to use UML.

There are several use cases that do apply beyond view menu / view brochure page - site functionality like print page, search site etc, sometimes accept a cookie to view specific content - but not much on classic brochure-ware. (All that ties well into user journeys / personas without having to restate the UX deliverables)

However, once using a system eg a CMS to create the website content - then I think the use cases get properly useful (as per comments above), as there are not only (usually) several actors inc the system, but also varying cases per content type so you can reference those UX deliverables without duplication and start filling in the gaps, plus tie up content strategy type deliverables (eg workflow & governance) by looking into the business processes and the system / user interactions. At the end of the modelling & specifications, you can get useful test matrices this way; plus class diagrams that relate objects to taxonomies (more agency deliverables to tie together in Functional Rqmts / Specs stage).

That's the way I'm trying to tackle it these days.

Siobhan
  • 11
  • 1
0

Use Cases can be used to model requirements of a system. System is a structure with input and output mappings. So if you have a static web page, you cannot interact with it in a other way than to view it.

As discussed in comments, if you think you did not understood the goals of stakeholders (what that word document sent by your boss ment...), you have to ask more and find them, use cases are a good technique for this.

In a cycle, discover actors (systems and roles interacting with the system you have to develop) and use cases (what needs of those actors the developed system should ssatisfy). Every time you find an actor, you may ask what other needs (possible use cases) he has and when you find an use case, you should ask who will participate in it and who is interested in it (who is the next actor and who are the stakeholders). Then you can define the scope boundaries and prioritize...

Gabriel Ščerbák
  • 18,240
  • 8
  • 37
  • 52
  • i agree with you, you have to show people what you mean and teach the clients to create definable needs rather than long emails with conflicting ideas. – Joseph Le Brech Mar 31 '11 at 09:52