I thoughtfully solve key business issues with regards to customer needs.
I reframe the initial brief by asking where the money is.
I help you the most in the beginning when things are not clear,
and the concept is only emerging.
I do UX, Product, Service Design, and Business Analysis.
The system is not reliable, it doesn't provide the key information to existing customers. Once the service is reliable, bringing in more customers by improving the registration process, makes sense.
π A common designer would only improve the registration process.
How we got thereπ¨βπΌ I want 80% of newly registered individual users to get one of our predefined contracts signed by the counterpart.
ππ»ββοΈ Ok, we can make on-boarding shorter, the steps clearer, CTAs more focused, Dashboard more helpful, etc. but where is the money?
π¨βπΌ ... sometimes the contract doesnβt reach the counterpart.
ππ»ββοΈ ???
π¨βπΌ Because the email is wrong.
ππ»ββοΈ And that's the key issue.
π¨βπΌ ???
ππ»ββοΈ The system doesn't recognize the wrong e-mail and pretends everything is ok. And when the customer finds out there is an error -> π‘
We don't force the user to make payment orders one by one, we help the user with an import of the file, by at least recognizing the format of the file.
π A common designer would prettify the single payment form. In the best case prettify the import wizard.
E-banking for corporate clients
π¨βπΌπ¨βπΌ We want you to optimize the single payment order form in e-banking for enterprise clients segment.
ππ»ββοΈ But there is no money in the form.
π¨βπΌπ¨βπΌ ???
ππ»ββοΈ Even SME segment users are uploading the list of payment orders, they don't use the single payment form. So we should focus on improving the import of the payment orders file.
π¨βπΌπ¨βπΌ Ok?
ππ»ββοΈ At least we should recognize the format of the file without compelling the users to tell us.
π¨βπ»π¨βπ» But it will not work in 100% of the cases.
ππ»ββοΈ Well, nothing does. 80% is good enough. There are like 4 ERP providers, so 80% should be achievable.
The templates of the documents are built out of the defined blocks. So the message of the document is clear and it also allows to build any new document in consistent way.
π A common designer would design the template, not the system for creating the templates out of the building blocks.
Show me moreThe agency supports the research projects through their whole life-cycle.
A lot of various documents with different kinds of messages are sent to the customers, depending of the state of project life-cycle.
Analyzing the existing documents β type, category, target group, etc. leads to defining new structure and then templates.
To keep consistency and also sufficient variability, it is necessary to define building blocks first β e.g. time, place, subject, etc. The aim is to build document tamplates out of these blocks.
It allows to deliver the clear message to the clients. It also saves the time of the employees preparing the documents and last but not least eliminates their unwanted βcreativityβ.
List in table view with horizontal scrolling is evil. The ability to sort by any column doesn't lessen the evil at all. For example there is a list with only 2 items (rows).
Internal info system for experienced employees. Focus on effeciency of every day tasks. Such tasks are like set new state to the list of items. Sometimes a lot of info must be displayed, the aim was to desplay it on one screen.
Way to go can be multiple rows within one row.
2 rows within one. No information was left behind.The column headers are gone, now we have sort of labels. The labels won't work. So, what if we get rid off them? Simply removing the labels doesn't make much sense but with a little bit of hierarchy, cleaning, units and descriptive states, it could do.
Such simplification can work for experienced users, but what about the newbies? Well, adding help probably in some kind of pop-up/lay-over, something like this
Replacing horizontal scrolling with vertical one makes sense in many cases. When using formatting and units properly, labels are unnecessary.
Ing. AleΕ‘ Brom
Kroupova 2756, Prague 5, CZE
βοΈ ales.brom@gmail.com
π± 602 655 775