Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm starting a new project from scratch and have written User Stores to describe how a given user will interact with the system. But, I'm having trouble understanding how to break the first user story in to tasks without the first one becoming an epic.
For example, if I were building a car and the first user story said something like "As a driver, I would like to be able to change the direction of motion so that I don't hit things.", that would imply a user interface (steering wheel), but also motion (wheels) and everything necessary to link those together (axle, frame, linkage, etc...). In the end, that first user story always seems to represent about 40% of the project because it implies so much about the underlying architecture.
How do you break user stories down for a new project such that the first one doesn't become an epic representing your entire underlying architecture?
You might want to think of your story as a vertical slice of the system. A story may (and often will) touch components in all of the architectural layers of the system. You might therefore want to think of your tasks as the work needed to be done on each of the components that your story touches.
For example, Let's say you have a story like In order to easily be able to follow my friends' tweets, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.
In order to accomplish this, you will have to pass through the UI layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.
Your tasks might be:
Add an option to the menu
Add a new gmail authentication screen
Add a twitter authentication screen
Add a contact selection screen
Add a controller that calls into your service layer
Write a new service that does the work
Save contacts to the database
Modify your existing gmail API calling service to get contacts
Add a twitter API calling service to follow selected contacts
There: That's 9 possible tasks right there. Now, as a rule, you want your tasks to take roughly 1/2 a day to 2 days, with a bias towards one day (best practice, for sizing). Depending on the difficulty, you might break down these tasks further, or combine some if they are two easy (perhaps the two API calling services are so simple, you'd just have a modify external API services).
At any rate, this is a raw sketch of how to break the stories down.
EDIT:
In response to more question that I got on the subject of breaking stories into tasks, I wrote a blog post about it, and would like to share it here. I've elaborated on the steps needed to break the story. The link is here.
When we started projects under a Scrum management style, the first set of tasks was always broad, or as you describe it: epic. That's inevitable, the framework of any project is usually the most important, largest, and time-consuming portion, but it supports the rest of the project. In order to pare down the scale on overwhelming-ness of how much there is to do see if you can list the MOST essential parts. Then work on defining those tasks as the starting points. Therefore you have a few tasks as starting points for a broad beginning. Hope that makes sense!
A user story describe the what while a task is more about the how.
There is no perfect formula, just add any task that describe how the user story is going to be implemented, documented or tested.
Keep in mind that a task should be estimated in hours, so try to scale and detail the tasks accordingly.
If you feel that you have too many tasks for a story (even if you have 1-8 hours long tasks), then maybe you should consider rewriting your user story in the first place because it's probably too complex.
Good luck
The story that you implement at the beginning can be refined over time. You dont need to think that every story has to be the final version that the user is going to use.
For example, in a recent project we had to develop an application which involved indexing various websites, and matching them against filters created by users, and finally alerting the user of matches (thing of it as google alert on steroids).
If you look at it from one perspective, there is only one story - "As a user I want to get alerts from matching pages". But look at it from another perspective of "what are the risks we want to mitigate". The first risk was that users wouldn't get relevant or better hits compared to google alerts. The second risk was in learning the technology to build this.
So our first user story was simply "As a user I want relevant hits", then we built just the hit matching algorithm on a hardcoded set of pages and hardcoded filters for some early users and got their feedback.
There might actually be a bit of back and forth here with multiple smaller stories to capture learning like "As a user I want more priority to be given to matches in the URL" etc.. these stories comes from the feedback as we iterate over what the early users consider "relevant hits".
Next, we broadened it to "As a user I want hits from specific websites" and we built the indexing architecture to crawl user specified sites and do hit matching on that.
The third story was "As a user I want to define my own filters", and we built this part of the system.
In this way we were able to build up the architecture piece by piece. Through most of the initial part, only early users could use the system, and many pieces of data were hardcoded etc.
After a point, early users could use the system completely. Then we added stories for allowing new users to register and opened it up to the public.
To cut a long story short, the story you implement first could implement only a small part of the final story, hardcoding and scaffolding everything else. And then you can iterate on it over time till you get the story that you might actually release to the public.
I've come to a crossroads with this issue in the past. User stories are supposed to be isolated so you can do them without any other stories, in whatever order, etc. But I found making that happen just made everything more complicated. To me this fell under the "Individuals and interactions over processes and tools" part of the agile manifesto - or at least my interpretation of it.
The ultimate goal is ship. And to ship you have to build, and to build you have to stop futzing with scrum and just get stuff done and make sure you track it.
So what we did was break a cardinal rule of stories and we made some tech stories like "create a preliminary schema". We also declared that some stories were dependent on others, and noted that on the back of the story card.
In the end I felt this type of story was few and far between, and the difficulty of the alternative justified the exception.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a newbie to the Agile/TDD world and trying to get my head around some of the basics.
This is related to the way I should go about implementing user stories.
For e.g. lets assume I have below 2 user stories to start with for a hypothetical content management system:
Story 1:
As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site
Story 2:
As an Editor
I need to be able to view existing articles
so that I can review them to improve the quality
The way I would approach this is,
I would grab one of these user stories
break the I need to part of the user story into smaller pieces of tasks
Grab these tasks one by one and come up with Tests to cover the specific task
Implement tasks the TDD way
Area where my dilemma is about the As a part of the user story.
Specially in these examples they indirectly imply some Authentication,Authorization related requirments to me since the user stories mention about two user categories.
So my question is, whether I should have any tasks/tests that control Authentication/Authorization to the system to complete these user stories
Or should I only focus on the I need to part of the user stories in trying to implement the functionality, and wait for any user stories that specifically mention about Authentication,Authorization related requirments?
All your inputs are highly appreciated.
Cheers.
Worry not about the implications at this stage.
A user story should be:
I Independent The user story should be self contained, in a way that
there is no inherent dependency on another user story.
N Negotiable: User
stories, up until they are part of an iteration, can always be changed and
rewritten.
V Valuable: A user story must deliver value to the end user.
E Estimable: You must always be able
to estimate the size of a user story.
S Sized appropriately or Small: User
stories should not be so big as to become impossible to
plan / task / prioritise with a certain level of certainty.
T Testable: The user story or its related description
must provide the necessary information to make testing the development
possible.
[Source, Wikipedia]
If they haven't been wriiten yet, you can add the authorisation stories to your product backlog for the product owner to prioritise. The authorisation stories may be picked up by some other team, such as your network administration or similar, so concentrate on delivering the functionaility requested by the story that you are working on.
You should definitely focus on the I need to part and consider the As a and so that as some kind of context.
There are many loopholes in your stories. The underlying Authorization/Identification part is one, another one I see is that the so that I attract more visitors to my website is something you can't really test, so you should think again and find another one (probably something simple and not very different like so that I can put them on my website to attract more visitors). I believe that with that format the so that part should contain some rough idea of how you'll test your story.
Really I use something much less formal for my stories : a title, a short description and some explanation of how to demo. I also add some priority value (important for the product owner) and a rough estimate of the work amount. The most usefull part is probably the How to demo as it will help writing tests (after breaking the story if necessary, but I also prefer, if possible, keeping stories shorts to avoid the need to break them). Also I try not to break stories to tasks but to smaller stories. Task is often too much about how you will do something and you should focus on what result you want.
In your case, there will most certainly be other stories and one will be about authentication someday, but that should not stop you to code pages now. Just go on step by step, keep your stories simple (you have tests, refactoring later is easy) and you'll quickly get the feeling of what works for you.
You should have a look at the excellent Book Scrum and XP from Trenches and see how they do it.
The phrase
"As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site"
is not the story. It is a summary of the story that fits on a card or in a spreadsheet column and represents the story so you can remember which one you're talking about. The whole story is composed of three parts - Card, Conversation and Confirmation - and the part you need here is the conversation.
Talk to the user or the user representative in your team to find out what it really means.
As a part does not imply Authentication or Authorization. In the same way you can write a user story as:
As a new visitor ...
As a returning visitor ...
Does it mean that visitor has to be authenticated? What authorization vistor has? User stories should not include "hidden requirement". If you need authentication and authorization simply create user story for that.
As a part specifies type of user roles in your application. Each role has some special needs and requirements and uses application from different reason. You should try to collect roles before you start to write user stories.
A user story does not contain only description. It should contain additional information which are added in different phases of the process.
Description in defined format. You don't have to use As a ... I need ... so that ... if you think it doesn't fit your needs but you should use same format for all stories.
DoD - definition of done also known as acceptance criteria. This should be collected with description. User story without DoD is useless. DoD says developer additional information about user story. User story is completed only if it fulfills DoD. You can also create automated acceptance tests based on these criterias.
Priority set by customer - this will help you sort user stories by importance
Estimate - made by team. Estimate is not exact it should be based on comparison among user stories. Usual units of estimate is abstract story point or t-shirt size.
Also be aware that not every user story is decomposed to tasks directly. You can have big high level user story which will be first decomposed to smaller user stories. We call such user story Epic.
You could initially make the assumption that the user is authorized to make changes, then tackle the authorization as separate stories later on (when they become the most important items in your backlog).
This has the benefit of keeping the scope of your stories small so they are easier to work with, and also gets the initial stories in a potentially deployable state earlier on.
At the very least I'd spawn stories for:
authenticate user
signup Author / Editor ... or signup User, assign permissions
If no one knows how that'd be handle those at the story level, I'd talk to/grab the phone/initiate im and check with them. You can TDD your way at the lower level for the feature that you wan't to implement, but any test automation on end-to-end story should go through what the user does.
The thing with those stories is that you might be thinking in the underlying tasks, but from the user point of view you might end up finding that the client wanted more of a blog with openid/login with existing account feeling. Its agile after all, its the way it rolls / full communication instead of an all defined in a large analysis + design phase.
No point in dedicating a sec of thought to usernames/password/hashes/etc when that might not even relate to the project.
Whatever you do, keep it simple.
ps. its all an integral part of the story, it just happens to depend on other stories being in place.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I currently work in a small business (15-20 employees, 5 programmers) where most projects are custom built CMS and a few web applications products.
Since I started working there, I have worked on many projects, but specifications for each project vary a lot. Sometimes we get a little detail, a Word document telling what the client wants, and what we are suggesting (suggested form fields, a short description of display, etc.). Sometimes almost nothing except "do what you think is the best approach for this project/module/request".
My question to you guys, who might work in different kind of businesses, is: How (huge pile of paper? Word docs? Visios?) and what kind of information do you get from your superiors, managers, teamates when starting a project (plenty of analysis, drawings, etc.)? How much detail do you get on this?
Hope my question is clear enough, thank you.
Specs..that's kind of funny...how about never :(.
Seriously a lot of companies assume specs aren't needed, its absolutely unacceptable but this is how it is in a LOT of companies. They assume a one liner and the programmer knows what the program should do, the inputs / outputs and so on.
Unfortunately in my case I have to actually help write the specs..and Im the programmer :(.
I mostly get a lot of verbal direction and I use a voice recorder to record the conversation and transcribe it when I am done. I write my own specs from my customers' words.
Then, as a good consultant should, I take the writeup back to the customer and verify it, and get a signature and build it, and they live happily every after! (no they dont, they change their mind a 100 times)
It can vary depending on what group the work falls under:
Support request - If the change will take a short period of time and is fixing something broken, there is this group. This could be as simple as, "Add Bob to the list of authorized users for that ancient form" where the form is something written years ago and aside from adding and removing users, it isn't touched for fear of breaking things.
Service Advisory Committee request - Items that are up to a few days are in this group as these are kind of like mini-projects as the request may be to create a new form or portal for a group. This could be upgrading some 3rd party software where we have some customizations that make the upgrade not necessarily a simple thing for Operations to do.
Project - In this case there are usually a few Word documents and/or e-mail threads that help nail down requirements in terms of scope, budget, and time. These can take months though there is something to be said for having a prototype to change rather than creating the initial prototype to tell if requirements are really met or not. Course my current project is over a year old, still has a few more months to the timeline and already has a successor coming after it is done,i.e. there is a Phase II to go after Phase I.
Uber project - These merit their own group of documentation and are the million dollar, multiple company projects that usually try to document everything up front rarely works out well here. Thus, there is some adoptioon of agile for these but there are still some growing pains to go through as how we use agile matures. Think installing a dozen modules of some off-the-shelf software that requires both internal and external developers to customize the suite for our specific needs as the software is supposed to be very robust, flexible and help save lots of time and money on how people otherwise do their jobs generally. Think ERP or CRM for a couple of examples here.
We are a 16-person company that creates and supports customized software for small retail shop owners.
The projects we get fall into three general categories (as related to specs):
"Here, automate this form." A sales person explains that our customer only wants this form to appear where they can fill it out and print it to make it look professional to their customer. Our specs is a single piece of paper that looks something like an order form or report. This is always false; they want pop-up lookups, automatic updating from other sources, and "while you're at it" add-ons that more than double the time. These, we've learned to just live in the moment and let the project take its course. By the time we're done, the program doesn't look anything like their original form.
Small changes. Like a simple e-mail explaining that the background color is stale, or a request to sort a report by a different column. These, we just do as time allows.
Big company integrations, where we're tasked with making our software work with some big outfit like Intuit (QuickBook) or FedEx (shipping rates). These often have well thought out documentation and sample code. We get 100's of pages in word documents or pdfs. The problem with these is when their specs are wrong. We find out about inaccuracies when we try to test or certify our integration. In these instances, we usually take longer in certification than we did to originally develop the processes.
In all cases, the real trouble is when a sales person promises a solution to the customer before even asking a programmer what it would take. As recently as 2 weeks ago, a sales person got into real trouble and had to issue a refund (that person is no longer with the company).
None - at least not from management.
Instead, as a developer (and particularly one leading a software project right now), I'm expected to contact my users/customers/etc and work directly with them to come up with our specifications and requirements. The documentation I do request from my team is only what will be useful to the team. I am lucky in that management rarely requests a document that doesn't make sense or won't provide some use to our project.
I currently have a half-dozen or so specs each 60-80 pages. One of them is 80 pages with no table of contents. Good times.
Our Product Managers and senior engineers prepare three planning docs for our data management software projects.
High-level requirements: 1-to-3 sentence descriptions of hardware/software supported or specific feature for this project. (10-15 pages of Excel-like grids)
Technical details: Engineering implementation of each high-level requirements. Up to a page for each, depending on amount of detail. (30-40 pages of filled-in feature details)
Business agreement: Summary of 1 & 2 with engineering schedule and Product Mgmt's market analysis. Everyone signs off on this. (5 pages analysis, 20 technical)
I haven't seen work flows or other Visio-like details in our specs. The prioritized requirements and schedule prove critical, so we understand when to lop things off to save development and testing time.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I am attempting to manage my projects a little better so I am looking at attempting to apply some of (eventually all) the features of scrum.
Looking at user stories specifically the high level format seems to be:
As a User I can Feature Description
or
Artifact is Doing Something
How would I write "Upgrade the Database"?
Is it simply Upgrade the Database?
I think I am being thrown off as there is no specific actor/customer and that the customer is the IT department.
AS A [person/role]
I NEED TO [do something]
SO THAT [provides business value].
For your example a user story might look like this:
AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.
I've added an acceptance criteria because without this you will never know when the job is done. Now at this point, you have a business case for upgrading the database. This story would be decomposed into a story where the role is the IT department or DBA, like so:
AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db
When story decomposition is added to your box of tools, the story must start from where the user is a real part of the business, and the "so that" leads to a real business value. Then decompose the story into one or more stories in which internal users do things "so that" real users get the benefits in need.
Here are a couple of articles that talk about Story Decomposition:
http://jpattonassociates.com/the_shrinking_story/
http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf
Scrum is not very prescriptive and there is nothing in Scrum that forces you to use User Stories for your Product Backlog Items (PBIs). You can definitely do Scrum without capturing requirements/features as user stories, user stories are just one way to do it. Actually, stories do work for many teams, especially web development teams, but this doesn't mean that they work in all cases and on every project (many projects are web development but not all, like in your case). There is no consensus about using stories.
That said, the recommended template for User Stories is actually As a <role>, I want to <action> so that <benefits>. I don't mean to be picky but, if you choose to use stories, I'd warmly suggest to use it as is, without removing any part. First, using a role do help (a same user/person can have several roles) to discover stories. Then specifying the benefits is really important to expose the business value of a story in order to prioritize them well. Regarding the value, you should think of it as end-user/customer ("put on customer glasses" --Mary Poppendieck). It is really not always that easy to express the benefits, but some tools might help and my preferred one is the 5 whys (which is used for root cause analysis).
In your case, this could lead to something like: As the IT department, I want the database to be upgraded so that users can benefits from the latest features of the application and [do a better job|have a better user experience] (not very satisfying though, use the 5 whys).
But personally I don't find that user stories are the best medium for technical tasks even if it is clearly possible to use them and if they have their strengths. Theoretically, stories capture the essence, not the details and should be a support for the discussion. I may be wrong but I don't find that technical tasks offer much room for discussion and creativity. So, depending on who will read them, what the should convey, I might use them or not. Another option could be to mix stories with another formalism for your PBIs. As I said, the point is not to use stories, the point is to have a list of prioritized and estimated items.
Upgrade the database may be one of the tasks involved in implementing another story that brings direct value to the user, for example I as a user can add a new foo to my bar.
If adding a foo to a bar requires a database upgrade behind the scenes, then you would include that work in implementing that user story.
User stories are worded this way to help ensure that any work directly benefits the end user in some way.
This gets to the forefront of why user stories are so great.
What benefit does upgrading your database give to the end user? None? Then don't spend the time and money doing it. Spend that time and money providing something that will give value to your end user.
If it does? Then think about it the other way. Maybe you can only implement a new feature when you have version x of your database software? In the dependency of the story, you could mention that database upgrade required to provide this feature.
tl;dr Don't just upgrade for the sake of it. Make sure upgrading adds tangible value to your customers.
Generally, technical tasks in the PB are frowned upon because they very rarely directly deliver business value to the customer. That's why User Stories are popular, because they force you to think about the business value of the story, and who it's being delivered to.
So, why are you upgrading the database? Can you identify business value in upgrading it, and why should the Product Owner agree to let you upgrade the database instead of building new features?
Is it because of a new feature that will make it possible or make it easier to do something in your application? In that case, that something should be the PB item, and the database upgrade should be a task within that story. If you already have stories on the PB that would benefit from the upgrade, then you should increase the estimates for one or more of those stories, and add the upgrade as a technical task to the story.
Is it because the vendor of the database is cutting off an old version from support? In that case you could have the upgrade as the story; something like, "As the department manager, I want to be sure that we have support for all of the software so that the continuity of the business isn't at risk if something goes wrong". Even that's pushing it, though. Generally, this kind of reason isn't really part of a project, unless the project has been going on so long the system software goes off support.
Is it for performance? Then the story should be about some aspect of the performance of the application that needs to be improved to deliver business value. Something like, "As a CSR I need to be able to retrieve customer information in a reasonable time so that customers on the phone are satisfied with our service". Then the upgrade becomes a task under that story.
Is it for some totally technical reason? If you can't identify how the upgrade is going to deliver business value, then why would you do it? Why would the Product Owner select it for a Sprint?
It's simply "Upgrade the Database" or maybe "When the new version is installed, there must be a way to migrate the existing database". If you already know more details about this step, then include them. But the story mostly exists to make sure something isn't forgotten; it's not to be detailed.
Later, when you get to implement this story, you can flesh it out (which tables, do we need one or more backups, is there a fall back scenario, etc).
OTOH, if the project is more complex, this can become a "tag", like a post-it notice which must be attached to many stories. That means you must include this as a "sub story" to all stories which change the database. As you can see, these "project-spanning stories" are a bit hard to track with agile methods.
Infrastructure stories do not need to follow the prescribed story template. Just write down what needs to be done and estimate accordingly
How about:
As the application support person I want to be on the latest version of database because it is more reliable / more secure / whatever.
You could even phrase refactoring like that:
As the application developer I want all the data classes in one module so that I can add new fields to the app very quickly.
Who benefits
What you want to do
What the benefit is
Ideally you don't want all the stories to have 1 be developers, but a few make sense (sharpening your ax instead of cutting down trees and all that).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What UI/GUI guidelines should be followed that subtly (or not so subtly) direct users so they don't shoot themselves in the foot.
For instance, you might want to give power users the ability to "clean" a database of infrequently used records, but you don't want a new user to try out that option if they've just spent hours entering new records - they may lose them all because they're 'infrequently used'. Please don't address this specific issue - it's just here to clarify the question.
While one could code a bunch of business logic in place to prevent some issues, you can't account for everything a user might do.
What are some common techniques, tips, and tricks that prevent improper usage?
ie, How should I design the interface to alert users that a function or action is to be taken with care
What should I design in that limits risk and exposure if a poor action is taken?
-Adam
Everything can be undone. Don't erase - deactivate. Back up before every destructive operation, and give the user a way to restore.
That's the path. It's hard to follow it all the way, but it's what you're aiming for.
Make it possible to undo dangerous actions.
If it's a reasonably big application or system, require separate admin access for dangerous operations as well.
Don't Make Me Think
And you can, in fact you HAVE to account for everything they might do. Because you (as the designer) as the one who gives them the ability to do all those things.
Before putting ANY item on a gui as yourself "Can this be misused?" and if it can, you might want to go with a lower level of customizability.
Example hierarchy
Button - Can be clicked.
T/F Radio Button (mandatory) - Only two options.
Combo Box - Many options, possibly "no option". more confusing.
Text field - Myriad of wildly inconsistent options. More confusing for user, more dangerous for coder.
Basically, if the user doesn't need extra options, then don't give them extra options. You'll only confuse them.
This is an old article, but it's still a great one:
Microsoft Inductive User Interface Guidelines
Never rely on anything that says "Are you sure?" The user is ALWAYS sure and that's if they even bothered to read it before dismissing.
Partition your users and have fine-grained permissions.
Define some power-user permissions that enable the "more dangerous" operations.
Power user permission is not given out lightly -- only to actual power users -- and revoked readily.
I'm of the school of thought that, in case of inclarities or ambiguousity, the user is rarely wrong, and the UI is always to blame. So, when you say "punch the user in the face", tagged with "pebkac", I'm thinking that you would do good with a slap in the face.
Unfortunately, I'm unable to give any good UX-advice, since I'm a mere programmer, and therefore more or less by definition disqualify as a good UI-designer. I'd like just to point out the possibility, that you actually could be the one who needs to get a clue, and try to be more humble towards the users.
Edit for Adam:
The little I know about UX is how little I know about it. It's an entire career path. I know for a fact that there's very little anyone can learn by asking a single make-me-good-at-this question at Stack Overflow. It's like me asking "help me write better code", with the body text formulated as a story of how my colleagues ridicule me of my code.
We, programmers, are engineers. We like order and reason and logical decisions. But the average user is not a programmer, not an engineer and, in many cases, not interested in computers themselves the very least bit.
I'm glad that people are giving you nuggets of good advice, and I'm glad that you, contrary to my first impression (I'm sorry about that), are eager to take those bits and understand the needs of the user.
But the point remains: You need to buy books (Don't Make Me Think is a great place to start, as already recommended). You need to watch how people use your software. You need to observe where they stumble, and jig things around until your UIs seem natural.
I'm sorry I still can't give you an answer. Because I don't have it. And even if I would have it, I would probably have to charge you 50EUR an hour, for years into the future.
Make the results of the user's action visible and offer a way to undo those changes.
When the changes are visible, then the user gets feedback of whether the results were what he intended to do, and if they are not, then the possibility to undo will let the user to try again to reach his goal. If possible, make the results of the action visible before the user invokes the action (for example, when dragging some element, show what would happen if the user would release the mouse button, for example visualize addition of the element where it will be moved to and visualize the removal of the element from where it was moved from).
There are a couple of types of undo. The most simple is a single-step undo (as in Notepad), but it is often not enough. Better is a multi-step undo (as in Word), which covers most of the cases, but does not allow undoing a specific action without undoing all the actions that have been done after it. That can be solved by object-specific undo, for example in a form with many fields (or cells in a grid like in Excel), right-clicking the field would show a list of previous values in that field. For deleted data you could have a store of deleted data, from where the user can restore things after deleting them (for example if the user deletes a slide in Powerpoint). And finally you could have a full version history of every change, for example as Local History works in IntelliJ IDEA - make a history entry every time the file is saved (and save everything automatically after a couple seconds of inactivity).
Confirmation dialogs don't help. The user might read it the first time, but soon after that clicking "OK" in the dialog becomes an automated process, and the user will press Enter before the dialog even shows up. Then the confirmation dialog has become just a source of unnecessary mechanical work. The user is always sure about doing some action, even when he is wrong - otherwise he would not have done that action.
Well there are a few different ways that I can/do go about these types of things.
User documentation - first and foremost give them some documentation to work with, and make the systems easy for them to use. Just general usability and descriptive names/actions for everything.
Provide confirmation screens with warnings. Full disclosure of what the action is going to do, with the warnings inside of a yellow box. It draws attention to it and helps prevent the need for the other items.
Have a roll-back plan. For large risky operations you can either simply set "deleted" flags, or offload the data to a temporary "recycle bin" of sorts should they accidentally remove/modify data that was unintended.
Require multiple approvals, for data purge operations especially go to a two-tiered approach, requiring approval from separate users.
These are just a few of the ideas that I have.
Two things immediately come to mind.
The first is the notion of progressive disclosure, i.e., only show users what they need in order to accomplish the task at hand. How many UIs have we seen that have hundreds of controls on a single dialog? Divide the controls into their respective tasks and only allow the user to do a single task at a time. An Advanced button on a dialog is one way to implement this, and this concept has the added benefit of separating the power users from the run-of-the-mill users. Run-of-the-mill users are less likely to attempt a task that is likely to be beyond their skill level.
The second is to leverage the wizard concept for complicated tasks. I know wizards have fallen out of style, but if a task is truly complicated, users usually appreciate having their hands held the first few times. A good example of this is the WinZip wizard interface. If you've never zipped a file before, this wizard uses a logical progression to walk you through the process. And then, once you've grown comfortable with it, you can switch to the classic interface to zip files more quickly.
Of course to do all of this requires a committment not only by the developers, but by management. And that, sadly, is where many of these usability battles are lost.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Say we are creating Acme CMS. This CMS web application will allow you to create an unlimited number of categories with sub-categories (unlimited depth), and each category can have 0+ content pages associated with it.
So this project, at a high level will have:
Front End
1. index page
2. category page with list of content pages
3. content page
Admin Control Panel
1. categories (add/update/delete)
2. pages (add/update/delete/)
Schema design
1. tables
2. stored procedures
3. data access layer
Questions:
I am using a bug tracker and Wiki, so how should I break this project down?
I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme).
When I have the user stories completed, I will then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one.
Am I breaking down this project properly? Any major gaps in planning that will make this project fail (in theory anyway!)
Please provide a detailed answer, maybe a general idea of what I should do, with a detailed example explaining it and why etc.
"I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme)."
Pages don't have stories. Users have stories. Pages are a thing you build to implement the user story.
The Theme -- if there is one for something this small -- is "managing content". Perhaps there are two themes: the collection of stories about writing/editing and the story(s) around browsing/reading.
Some users ('editors'?) want to create, organize, update and remove content so they can something [the question doesn't say]. You force them to use web pages because it's better - cheaper - faster than 5x8 cards and markers.
Some users ('readers'?) want to examine content and navigate so they can -- who knows? -- be happier and more productive at something. You force them to use web pages because it's somehow better than 5x8 cards held to a whiteboard with magnets.
You have stories about the theme of creating and managing content.
"then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one"
Right. And the features have to begin with data model first, then presentation in some useful form. Perhaps on pages. Indeed, once you have a model that satisfies the use cases in a broad way, you can fine-tune the presentation to make the model more usable.
"business layer & presentation is what I need to detail"
Model == business layer. They're the same thing.
Pages == presentation. Note. This is last. Once you have use cases and a model that supports those use cases, you can present your stuff to people so they can interact with the model.
As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:
Design a domain model first, and then design business layer, then UI and data model.
Start with data model and build business layer and UI on top of it.
Model the UI first, then everything else.
Regardless of which path you would prefer to take (or combination of) there are some general guidelines:
Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.
Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.
Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces.
Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.
At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.
All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process.
Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.
The "unlimited" part is broken... even GMail has an upper limit...
Edit: Although my answer got downvoted I think it is right. As soon as you talk with non-programmers the "unlimite" parts become very dangerous, and will likely stab you in the back. Also you can't really have a scalable data schema for unlimited nesting... but that should be obvious.