Archive for the ‘Use Cases’ Category

Government Software Design Questions

Saturday, July 19th, 2014

10 questions to ask when reviewing design work by Ben Terrett.

Ben and a colleague reduced a list of design review questions by Jason Fried down to ten:

10 questions to ask when reviewing design work

1. What is the user need?

2. Is what it says and what it means the same thing?

3. What’s the take away after 3 seconds? (We thought 8 seconds was a bit long.)

4. Who needs to know that?

5. What does someone know now that they didn’t know before?

6. Why is that worth a click?

7. Are we assuming too much?

8. Why that order?

9. What would happen if we got rid of that?

10. How can we make this more obvious?

 

I’m Ben, Director of Design at GDS. You can follow me on twitter @benterrett

A great list for reviewing any design!

Where design doesn’t just mean an interface but presentation of data as well.

I am now following @benterrett and you should too.

It is a healthy reminder that not everyone in government wants to harm their own citizens and others. A minority do but let’s not forget true public servants while opposing tyrants.

I first saw the ten questions post in Nat Torkington’s Four short links: 18 July 2014.

Writing Effective Requirement Documents – An Overview

Friday, March 29th, 2013

Writing Effective Requirement Documents – An Overview

From the post:

In every UX Design project, the most important part is the requirements gathering process. This is an overview of some of the possible methods of requirements gathering.

Good design will take into consideration all business, user and functional requirements and even sometimes inform new functionality & generate new requirements, based on user comments and feedback. Without watertight requirements specification to work from, much of the design is left to assumptions and subjectivity. Requirements put a project on track & provide a basis for the design. A robust design always ties back to its requirements at every step of the design process.

Although there are many ways to translate project requirements, Use cases, User Stories and Scenarios are the most frequently used methods to capture them. Some elaborate projects may have a comprehensive Business Requirements Document (BRD), which forms the absolute basis for all deliverables for that project.

I will get a bit deeper into what each of this is and in which context each one is used…

Requirements are useful for any project. Especially useful for software projects. But critical for a successful topic map project.

Topic maps can represent or omit any subject of conversation, any relationship between subjects or any other information about a subject.

Not a good practice to assume others will make the same assumptions as you about the subjects to include or what information to include about them.

They might and they might not.

For any topic maps project, insist on a requirements document.

A good requirements document results in accountability for both sides.

The client for specifying what was desired and being responsible for changes and their impacts. The topic map author for delivering on the terms and detail specified in the requirements document.

Seeking Creative Use Cases for Thomson Reuters Web of Knowledge

Thursday, January 31st, 2013

Seeking Creative Use Cases for Thomson Reuters Web of Knowledge

From the post:

AWARD: $10,000 USD | DEADLINE: 2/24/13 | ACTIVE SOLVERS: 467 | POSTED: 1/18/13

This Challenge seeks use cases for Thomson Reuters Web of Knowledge content, tools, and APIs (Application Programming Interface) that would enable users to engage in creative new behaviors, beyond what is currently possible with online research portals. How will users want to search and discover scholarly content throughout the next 5 years?

This Challenge is an Ideation Challenge, with a guaranteed award for at least one submitted solution. In this first phase, the Seeker is looking for creative ideas/use cases; no programming or code delivery is required.

See the post for details and links.

Only the best idea is required. No eye candy to cover up a poor idea.

Listen to Your Stakeholders : Sowing seeds for future research

Sunday, December 2nd, 2012

Listen to Your Stakeholders : Sowing seeds for future research by Tomer Sharon.

From the post:

If I needed to summarize this article in one sentence, I’d say: “Shut up, listen, and then start talking.”

User experience practitioners who are also excellent interviewers know that listening is a key aspect of a successful interview. By keeping your mouth shut you reduce the risk of verbal foibles and are in a better position to absorb information. When you are concentrated in absorbing information, you can then begin to identify research opportunities and effectively sow seeds for future research.

When you discuss future UX research with your stakeholders you want to collect pure, unbiased data and turn it into useful information that will help you pitch and get buy-in for future research activities. As in end-user interviews, stakeholder interviews a word, a gesture, or even a blink or a certain body posture can bias an interviewee and add flaws to data you collect. Let’s discuss several aspects of listening to your stakeholders when you talk with them about UX research. You will quickly see how these are similar to techniques you apply when interviewing users.

Stakeholders are our clients, whether internal or external to our organization. These are people who need to believe in what we do so they will act on research results and fund future research. We all have a stake in product development. They have a stake in UX research.

Tomer’s advice doesn’t require hardware or software. It does require wetware and some social interaction skills.

If you are successful with the repeated phrase technique, ping me. (“These aren’t the droids you are looking for.”) I have a phrase for them that starts with a routing number. 😉

Use Case Zero for Topic Maps, Returns

Thursday, November 1st, 2012

Steve Newcomb once described for me the first conversation where something recognizable as topic maps was discussed.

Government agencies were interested in not paying for duplicated or largely duplicated documentation.

Not hard to imagine that every time something changed on one of these:

F-15 Eagle

You don’t want a duplicate of the original documentation, plus a page or two for the change. You want the page or two.

If you could also integrate the new page or two into your systems for the old, well, you get the idea.

Imagine my surprise to see:

Want to get rid of documents with duplicate content? by Don Pinto.

From the post:

Whether you’re combining data from two different data sources, have multiple purchases from the same customer or just entered the same data in a web form twice, it seems like everyone faces the problem of duplicate data at one point or the other.

In this blog post, we’ll look at using views in Couchbase Server 2.0 to find matching fields among documents and retain the non duplicate documents. For the sake of this example, assume each document has three common user specified fields – first_name, last_name, postal_code. Using the ruby client for Couchbase Server and the faker ruby gem, you can build a simple data generator to load some sample duplicate data into Couchbase. To use ruby as a programming language with Couchbase, you should download the Ruby SDK here.

Topic maps also address ambiguity, synonymy and collocation of data about a subject, but it’s interesting to see use case zero again.

Of course, fields aren’t sufficient for complex collation of documentation but it is the same general use case.

Perhaps government agencies will return to the quest for more robust documentation management in these budget conscious times.

Suggestions on texts to demonstrate such a use of topic maps?

DEITY Launches Indian Search

Sunday, October 21st, 2012

DEITY Launches Indian Search by Angela Guess.

From the post:

Tech2 reports, “The Department of Electronics and Information Technology (DEITY) unveiled Internet search engine, Sandhan, yesterday to assist users searching for tourism-related information across websites. Sandhan will provide search results to user queries in five Indian languages – Bengali, Hindi, Marathi, Tamil and Telugu.

[Which further quotes Tech2:] With this service, the government aims to plug the wide gap that exists ’in fulfilling the information needs of Indians not conversant with English- estimated at 90 percent of the population’.

Let’s see: 1,220,200,000 (Wikipedia, Demographics of India, 2012 estimated population) x 90% (not conversant with English) = Potential consumer population of 1,098,180,000.

In case you are curious:

1,344,130,000 (Demographics of China, 2012 estimated population) is reported to have two hundred and ninety-two (292) living languages.

503,500,000 (Demographics of EU, 2012 estimated population) has twenty-three (23) official languages.

Wikiipedia has two hundred and eighty-five (285) different language editions.

No shortage of need, question is who has enough to gain to pay the cost of mapping?

Collaborative Systems: Easy To Miss The Mark

Sunday, October 21st, 2012

Collaborative Systems: Easy To Miss The Mark by Jocob Morgan.

From the post:

Map out use cases defining who you want collaborating and what results you want them to achieve. Skip this step in the beginning, and you’ll regret it in the end.

One of the things that organizations really need to consider when evaluating collaborative solutions is their use cases. Not only that, but also understanding the outcomes of those use cases and how they can map to a desired feature requirement. Use cases really help put things into perspective for companies who are seeking to understand the “why” before they figure out the “how.”

That’s what a use case is: the distilled essence of a role within your organization, how it will interact with some system, and the expected or desired result. Developing use cases makes your plans, requirements, and specifications less abstract because it forces you to come up with specific examples.

This is why we created a framework (inspired by Gil Yehuda) to address this. It breaks down as follows:

  • — Identify the overall business problem you are looking to solve (typically there are several).
  • — Narrow down the problem into specific use cases; each problem has several use cases.
  • — Describe the situation that needs to be present for that use case to be applicable.
  • — Clarify the desired action.
  • — State the desired result.

For topic maps I would write:

Map out use cases defining what data you want to identify and/or integrate and what results you expect from that identification or integration. Skip this step in the beginning, and you’ll regret it in the end.

If you don’t have an expectation of a measurable result (in businesses a profitable one), your efforts at semantic integration are premature.

How will you know when you have reached the end of a particular effort?

30 MDM Customer Use Cases (Master Data Management in action)

Friday, March 16th, 2012

30 MDM Customer Use Cases (Master Data Management in action)

Jakki Geiger writes:

Master Data Management (MDM) has been used by companies for more than eight years to address the challenge of fragmented and inconsistent data across systems. Over the years we’ve compiled quite a cadre of uses cases across industries and strategic initiatives. I thought this outline of the 30 most common MDM initiatives may be of interest to those of you who are just getting started on your MDM journey.

Although these organizations span different industries, face varied business problems and started with diverse domains, you’ll notice that revenue, compliance and operational efficiency are the most common drivers of MDM initiatives. The impetus is to improve the foundational data that’s used for analysis and daily operations. (Click on the chart to make it larger.)

Curious what you make of the “use cases” in the charts?

They are all good goals but I am not sure I would call them “use cases.”

Take HealthCare under Marketing, which reads:

To improve the customer experience and marketing effectiveness with a better understanding of members, their household relationships and plan/policy information.

Is that a use case? For master data management?

The Wikipedia entry on master data management says in part:

At a basic level, MDM seeks to ensure that an organization does not use multiple (potentially inconsistent) versions of the same master data in different parts of its operations, which can occur in large organizations. A common example of poor MDM is the scenario of a bank at which a customer has taken out a mortgage and the bank begins to send mortgage solicitations to that customer, ignoring the fact that the person already has a mortgage account relationship with the bank. This happens because the customer information used by the marketing section within the bank lacks integration with the customer information used by the customer services section of the bank. Thus the two groups remain unaware that an existing customer is also considered a sales lead. The process of record linkage is used to associate different records that correspond to the same entity, in this case the same person.

Other problems include (for example) issues with the quality of data, consistent classification and identification of data, and data-reconciliation issues.

Can you find any “use cases” in the Infomatica post?

BTW, topic maps avoid “inconsistent” data without forcing you to reconcile and update all your data records. (Inquire.)

Documenting decisions separately from use cases

Thursday, March 15th, 2012

Documenting decisions separately from use cases by James Taylor.

From the post:

I do propose making decisions visible. By visible, I mean a separate and explicit step for each decision being made. These steps help the developer identify where possible alternate and exception paths may be placed. These decision points occur when an actor’s input drives the scenario down various paths.

I could not have put this better myself. I am a strong believer in this kind of separation, and of documenting how the decision is made independently of the use case so it can be reused. The only thing I would add is that these decisions need to be decomposed and analyzed, not simply documented. Many of these decisions are non-trivial and decomposing them to find the information, know-how and decisions on which they depend can be tremendously helpful.

James describes development and documentation of use cases and decisions in a context broader than software development. His point on decomposition of decisions is particularly important for systems designed to integrate information.

He describes decomposition of decisions as leading to discovery of “information, know-how and decisions on which they depend….”

Compare and contrast that with simple mapping decisions that map one column in a table to another. Can you say on what basis that mapping was made? Or with more complex systems, what “know-how” is required or on what other decisions that mapping may depend?

If your integration software/practice/system doesn’t encourage or allow such decomposition of decisions, you may need another system.

James also cover’s some other decision management materials that you may find useful in designing, authoring, evaluating information systems. (I started to say “semantic information systems” but all information systems have semantics, so that would be prepending an unnecessary noise word.)

Suffering-Oriented Programming

Wednesday, February 8th, 2012

Suffering-Oriented Programming by Nathan Marz.

From the post:

Someone asked me an interesting question the other day: “How did you justify taking such a huge risk on building Storm while working on a startup?” (Storm is a realtime computation system). I can see how from an outsider’s perspective investing in such a massive project seems extremely risky for a startup. From my perspective, though, building Storm wasn’t risky at all. It was challenging, but not risky.

I follow a style of development that greatly reduces the risk of big projects like Storm. I call this style “suffering-oriented programming.” Suffering-oriented programming can be summarized like so: don’t build technology unless you feel the pain of not having it. It applies to the big, architectural decisions as well as the smaller everyday programming decisions. Suffering-oriented programming greatly reduces risk by ensuring that you’re always working on something important, and it ensures that you are well-versed in a problem space before attempting a large investment.

I have a mantra for suffering-oriented programming: “First make it possible. Then make it beautiful. Then make it fast.”

First make it possible

When encountering a problem domain with which you’re unfamiliar, it’s a mistake to try to build a “general” or “extensible” solution right off the bat. You just don’t understand the problem domain well enough to anticipate what your needs will be in the future. You’ll make things generic that needn’t be, adding complexity and wasting time.

Different perspective than Semantic Web proposals for problems that users don’t realize they have. (Topic maps have the same issue.)

I was going on, probably tiresomely, to my wife about a paper on transient hypernodes/hyperedges and she asked: “Is anyone using it now?” I had to admit 22 years after publication, it had not swept the field of IR.

She continued: “If it was so good, why isn’t everyone using it?” A question to which I don’t have a good answer.

RDF and OWL interest the W3C and funders of research projects but few others. There is no ground swell demand for an ontologically enabled WWW. Never has been.

At least not to compare to the demand for iPads, iPhones, photos of Madonna/Lady Gaga, NoSQL databases, etc. All of those do quite well without public support.

But then there is real demand for those goods/services.

Contrast that with the Semantic Web which started off by constructing universal and rigid (read fragile) solutions to semantic issues that are in a constant process of dynamic evolution. Does anyone see a problem here?

Not to excuse my stream of writing about topic maps. Which posits that everyone would be better off with mappings between representatives for subjects and their relationships to other subjects. Maybe, maybe not. And maybe if they would be better off, they have no interest.

For example, for sufficient investment, the World Bank could enforce transparency down to the level of national banks or lower for its disbursements. That begs the question whether anyone would accept funding without the usual and customary opportunities for graft and corruption? I suspect the answer both within and without the World Bank would be no.

A little bit closer to home, a topic map that maps “equivalent” terms in a foreign language to subject headings in a library catalog. Composed by local members of a minority language community. Not technically difficult, albeit it would require web interfaces for the editing and updating. How many libraries would welcome non-librarians making LC Subject Classifications accessible to a minority language community?

Here’s a question for suffering-oriented programming: How do we discover the suffering of others? So our programming doesn’t satisfy the suffering of an audience of one?

Approaching and evaluating NoSQL

Wednesday, August 31st, 2011

Approaching and evaluating NoSQL by Mårten Gustafson.

From the webpage:

Brown bag lunch presentation at TUI / Fritidsresor about approaching and evaluating the NoSQL area. Embedded presentation below, downloadable as PDF and Keynote.

A “brown bag lunch” presentation that balances detail with ideas so listeners will follow it with interesting conversations and research.

The “use case” approach lends itself to exploring “why” someone would want to use a NoSQL database as opposed to the usual mantra that NoSQL databases are flexible, scalable and fast.

So? If my data format is fixed, not all that large (under a few terabytes), and I run batch reports, I may not need a NoSQL database. Could, depends on the facts/use cases. This presentation gets high marks for its “use case” approach.