|
I start thinking about how to keep the user interface simple right from the start and continue updating it based on feedback from users after deployment. My goal is to make it so they don't have to think about the UI, which allows my users to concentrate on their job and not my application.
|
|
|
|
|
Internal - developer, Internal - business, external - clients, public at large ?
That dicates both features and UX. And those dictate API.
Respondents here who say they push the UX to later are really saying "Our intended target is internal users, and they can just suck it with whatever we give them" which is still a UX choice.
Truth,
James
|
|
|
|
|
This was particularly odd to answer in this way, but then I thought about transitioning from the barebone tools you usually run on a command line (Workflows precede all-in-one interfaces).
Videogames are first and foremost the user experience so it's the opposite of designing a tool. But even in videogames you sacrifice the user feedback for the finished product because, unless you are forever updating the game, you have to take it into consideration for the next game and leave the finish product on the shelf.
Creators of 3D modeling tools, simulators and heavy number crunching applications have two serial priorities before the user interface, that is 'get it to work' and then 'get it to work faster'.
|
|
|
|
|
Planning is prep work to get things going -- there is no option for "design", which is determining how the application will function. The UI cannot be designed until the functionality is defined. Once we know what the application needs to do, then we can determine the best way to present it to the users in the most intuitive and useful fashion.
|
|
|
|
|
Considering my frequent suggestions to MS re/ VS UI I conclude subtleties exist which can best be found when polishing/using/experiencing as I presume the gross UI is obvious at least a workable version thereof
|
|
|
|
|
even if the user is a power user/pro/yourself, the thing being made is OFTEN made it: make faster, quicker, eaiser, shorter or some mix of.
includes making command line functions - why make a short hand function for something, or automating anything, its to reduce or make easier for the perspective of said user.
Wireshark might look over complicated and too busy, but its aimed at someone that needs that info.
|
|
|
|
|
Perhaps something that supports what the user will actually use - something transparent to the user. I suppose that could be considered user experience, but that's not the way I define it.
Also, there may be multiple types of users, as with event/ticketing apps. One user has a ticket to sell and needs to set up the forms for registration; another user is using those forms to get the ticket for the event. Which are you designing for and what does the engine need to produce the results you will be storing?
Yes, it's 'for' the user, but the actual contact with the user (what I define as the UX) is only one part of that service.
|
|
|
|
|
Firmware, drivers, kernels. The user doesn't interact with the BGP implementation on a router, with the device driver of their peripherals or the memory management module of the OS.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
It should be part of the project specifications.
Those should be implemented during the application creation, with intense scrutiny.
After the application is released to the Users and 10,000 questions, suggestions and complaints are raised. the Users almost never know what they want for an interface until they see the one you have designed.
|
|
|
|
|
implementing the code is the following task. Important is also which data is available and the user may use or look at.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
|
Yes.
During 1 sprint, our PO sits down with clients that represent major groups within our user base, and he asks them what they need and what they would like.
He writes out the rough flow for a new feature or improvement, doublechecks with different clients and professionals, and then he asks UX to draw up the mocks, and to amend any UX mistakes he has made.
After that's done, he will divide the work between himself and functional profiles, to write out the user stories, and he checks with architecture and other teams to determine the acceptamce criteria.
At that stage we typically prep the next sprint, so the team has to refine and block, depending on what is technically sound, and what isn't. Blocked items get researched by the team itself during the sprint, everything else refined gets implemented next sprint or layer, depending on what the team thinks is feasable.
We only build things that our costumers have a use for, and we don't take outside direction, so we're agile, autonomous, and profitable.
|
|
|
|
|
When used in the proper manner, even the waterfall model is agile. When I hear agile evangelists telling what waterfall was, it appears like a nightmare, a horror cabinet, that is just as scary to me (who grew up with waterfall) as it is to the agilers.
I never saw any waterfall with any trace of resemblance to the horrors we today learn that it represented. When it was the standard approach, it was essentially a rough framework of "Thinking before doing". Define the goals, both intermediate and final goals. Do first things first.
The way you describe it, you are taking the first steps back towards waterfall approach: Decide what you want to do before doing it. First things first. I see more and more of that as people gradually dare to stop and think what pure agility thinking has lead to. Nowadays, it is proper to say that you first sit down with the users to ask them what they want and need, before setting up the code framework - as long as you call it 'agile'. Even the slightest mention of waterfall ideas, as I do here, makes any modern developer stall and frown. (I have got my asbestos suit ready  ).
We just have to find another term, with no reference to waterfall, to describe a revised methodology. To keep the 'pure agility' evangelists happy, it should make clear references to agile(*), such as 'Structured Agile Development, SAD. I would think that your step-by-step think-and-then-do style would fit well into such a SAD style.
(*) Just like every networking textbook in the 1980s described the 'layered' structure of the TCP/IP stack - it breaks every single principle of proper layering, but 'layered' was included in the descriptions to make academics love it, even in Europe.
|
|
|
|
|
Just wanted to give feedback: I fundamentally agree with your assessment.
Nothing inherently horrific about waterfall, but applying it like a lot of companies did 20 years ago, it basically resulted in 1 or maybe 2 releases a year. Which meant customer feedback often had little to no place, and most decisions got watered down by internal politics.
Agile just makes it a little harder for internal politics to steer things into a cliff.
That's progress.
|
|
|
|
|
Asterisk because in my case the User Experience is either "car doesn't crash and burn + car doesn't burn" or "car brakes when depressing the brake pedal", so I did answer in a very theoretical situation where I have to work on a application with actual UI/UX.
When I did work on user facing applications they were already on the market so design phase was already thrice over, and I suppose this holds true for the majority of software developers. At least in my experience the chance to write something from the design phase is very low, it's usually maintaining / expanding / refactoring something that's already out there in the wild.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Apart from the users, you mean? 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
It seems like that is much too rare to find software where you feel like the programmers really DO care about the user experience. There are times when I find myself wishing that the programmer be tortured by being forced to use his own product.
Brent
Brent
|
|
|
|
|
My sister used to say "They have no mothers to give it to them for testing? It is usable when their mothers can use it."
|
|
|
|
|
Screw the user, let them learn the program as is, and live with it!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
