Basically I’m trying to work out the real kink in process were UI moves between idea->wireframes-> code->final approved screens. The pain I have is that people not only use different language when saying user experience , but completely exclude performance, quality and only talks “workflow”. Loads of places I have worked, it is just loads of pictures given to the developers. Pictures which get hard to keep updated, are less useful to the tester who has to verify them, and also don’t capture “implicit” design experiences or rules like
do all buttons start out disabled when a form is empty, or
do all fields have hint-bubbles.
Things, that are all rather tedious to show in wireframes.
As someone who has stuck my head above the parapet on the whole UI experience and the accessibility thing, I’m looking for more hints on how to communicate to stakeholders. Waiting until all the screens have been coded up, before we decide, no this one does not quite look right, is a pretty terrible idea. Mainly because a developer who last worked on a piece a month or so ago needs to go back, but also that testing gets impacted. Developers are often focused only on the component they are working on, so consistency will often suffer. Testers can get builds long before stakeholders get to see the resulting screens, so are well placed to spot issues early, but without any good communication skills, where do I start?
We create a clickable mock-up design. Which already helps tons!
Correct! After each daily we have a 30 minute window which can be used for ‘grooming/code Q&A/anything really’. (This doesn’t need to take place only if something is available) We use this time sometimes to show the clickable mockup designs to the whole Dev+QA+Stakeholder team, even when we only have a little bit prepped and work is only 20% finished. Showing it more iterative to the team will get you faster feedback. A technical tester might say ‘that’s going to give performance issues’ and a dev might say ‘that’s not going to work for our back-end’.
This way the whole team will also be up to date with the new features and business process behind it and where the idea is coming from. + there is super fast feedback
I would introduce some kind of review system. Early on the SDLC. perhaps get that clickable mock-up design. That way you can solve your issue of your buttons. Your buttons will become enabled when you click on X or Y. (Which is also a written rule of course)
We are currently using this system and it helps us TONS! I wouldn’t want it otherwise.
We do have the clickable mock-ups, I think it’s great, but it’s no replacement for a walkthrough with a real live person.
We have a sprint-end-demo, which is a good time to show things, the “daily” problem is that the stakeholder is not present in daily standup, and it’s not currently the forum to ask things like “is the font here correct?” The fortnightly demo likewise gets overshadowed, because not everyone cares that the positioning of a button looks a bit strange. Demos are supposed to be of completed work, but in my mind, that’s too late.
I guess we just have not really “put design into our SDLC” at any place I have ever worked. Design is often treated like security gets done in many places, as an external process. I never used to engage with design thinking at all before, and finding it’s a real struggle to get that wheel turning, especially with most people not being in a real office.
I think, you have triggered the answer for my context at least @kristof . I kinda wish someone had pointed this out to me decades ago. Having mock-ups in a easy to access place is key, it’s a failing of our software development process quite often, to not communicate regularly across teams or silos. (If you want to join some of these live discussions you can also drop into the MOT Google hangouts channel here Sign in - Google Accounts)
Then: Whenever external teams are involved, its creates a process friction , which is sometimes good friction. But teams have a habit of operating in silos, so creating a healthy channel that exists only to allow balance to happen is good. Whenever a problem sits across 2 teams, either the team that shouts the loudest, or the team that has the most time and people, is going to win. And often that means engineering win, which, is the team that often choose for lowest cost. Within constraints that they know about. So unless a product owner says yeah, we are prepared to spend more on this feature, it’s going to be the cheap and nasty version.
Which: After a cool chat with Stuart this morning led me to this conclusion in my current context. Quality software is about correctness, something which is actually very temporal. And so we have to be prepared to run some A/B tests, but we also have to be prepared to look for the lowest friction outcome for customers. If the Marketing came and said UX must look and do this, but Engineering know that customers really want quick journeys, then quick journeys need to win. We just need to tell Marketing early, about the choice we made, and do it respectfully, in a way that fits with our product process. This same friction we see in our product development process, often maps into unnecessary frictions for end users. Development processes are just models, and we all know the argument about models being only useful when things are going well for us and the world playing nice. Communicating what was decided, sometimes doing that in code, because wikis are a shite place to write stuff down and then leaving people bandwidth to give feedback. Customers want the feature now, they also don’t want the “feature”, they really want to get their day tasks done, logout, go home and get paid.
To them your feature, is just a question of How long do it have to push buttons for, until I get paid?
At least you asked XD