Currently trying to untangle the giant ball of hair that is legacy platforms/enterprise level tools/lack of understanding for UX within our org. Everyone loves to design shiny, new customer-facing products—but what about the incredibly dense internal stuff? Any words of wisdom for navigating these things?
Make sure you talk to the people who actually use the product. And when you talk to them make sure the product owner and any other stakeholders are there to hear the feedback firsthand.
Also, keep a firm eye on the engineering team to make sure they actually implement what you handoff.
To add, I've also found that they're often in the dark about the greater business goals and product roadmap, so just spending time to walk them through the design and thought process is greatly appreciated. They want to build a good product too.
I totally agree. It's good to have everyone able to peek in on and give feedback at all parts of the process. I just have experience with Microsoft engineering teams not coming to any design meetings, even engineering hand off meetings, and then when the design gets delivered, they take it and make changes to it without communicating back to the team.
There's no shame in using bootstrap enterprise UI patterns. It will speed up your delivery of mockups and free you up to focus on the main task which is untangling the Gordian knot of legacy workflows.
1. backward compatible, 2. worst case scenarios.
Designing for Enterprise software is normally not the sexiest, mostly due to its robust functionality. I would really focus on content and IA + elevating design principles. Use progressive disclosure techniques to only present what is necessary at any given time.
Start small. You've discovered how knotty things are, and with that comes the temptation to overhaul everything--big plans, extensive road maps, all driven by a genuine desire to improve operations and output. It sounds *great* but it's difficult to, as consultants would say, "boil the ocean." I used to work with a small UX consultancy and we had the best outcomes by working closely with a few IT executives. In the long run, you'll need greater and wider executive alignment to get anything done (obviously), but that's hard. Prove value by addressing a smaller, targeted opportunity that can give you some hard metrics--we also collaborated with the Six Sigma blackbelts, which gave more quantified value to the work. Set up some small, quick workshops; do journey maps that can be understood without having to examine them too closely. Typically, we'd do maps that could be read from a distance of 10ft away. That sparked a lot of discussion, and when people start talking, the ensuing dialogue can lead to broader recognition that there's a problem and a way forward. PM me if you like, I enjoy chatting about these things.
Shadow end users and find easy UX workflow wins that save time and can have a direct cost savings calculated. Do this two or three times and then you could pitch a longer roadmap for larger features. When shadowing, don't just look for what, always be looking for why.
No real advice except that it can be frustrating having a head full of forward thinking design paradigms and everyone of your stakeholders and users still print out emails. Breathe. Take your time and if you are a ux team of one really and I mean really push the idea that no pixels committed does not mean work is not happening. Understanding deep problems takes literally forever
You might have to start some form of Design education, Lunch and Learn. Tell the about success of organization that focus on design. IBM is spending millions of dollars hiring hundreds of designers. Saying IBM instead of Facebook because it's an enterprise company that still exists from early days of computers.
Try to gather as many business requirements as possible but don't hurry to implement them all. Try to gather some metrics if possible. People tend to demand to replicate the features no one uses just because they were there forever. If possible try to go live with limited functionality and prioritize based on what users are actually asking for.
and attempt to integrate frequently and early, spec and requirement are often incomplete and wrong.
+1 on this. Also, dig deep to understand why the business does things the way they do. Sometimes it was an old decision that no longer makes sense. But there are also times when a process seems weird or unnecessary, you change it you think for the better only to later realize there was a good reason for it. Don't assume all past decisions were made by idiots and are devoid of wisdom.