A potential employer asked why a UI/UX designer would also be interested in middleware software development and back-office software integration. For me, that answer is simple.
A.E.Veltstra
October 2014
In 1993 I started out as a website designer and developer. In 1998 I became a professional developer of administrative and financial office software. UI design was (and still is) an important part of that work. Me and my colleagues performed all tasks connected to software development except selling it.
Later on (say, turn of the century) the company's focus changed to create web-based applications connected to either existing or entirely new back-office systems. Having sound experience with both, I was chosen to head my teams. Around that time the differentiation between front-end, middleware, and back-end became solidified, and a new kind of professional stood up, who focused on UI and UX only, 2 kinds of work that for me and my colleagues always had been part of our daily jobs.
As such, I am now known as a full-stack developer. I can do all of the work (if I am familiar with the technology stack), starting with gathering customer requirements, ending with training them and their customers to use what was built, and everything in-between. With that experience I realised that I prefer not to do everything by myself, and instead like to have specialised technicians execute dedicated parts of the project.
I never lost my touch with UI development and UX design. I believe that the best interface is no interface at all: let's just get to the desired result. I understand there are choices to be made before the end result is available, and the interface must make it as easy as possible to get there. It should not pose problems. It should not restrict access based on arbitrary choices like a technology stack, screen size, or bandwidth, nor restrict functionality to people with disabilities. It should be intuitive, and of course what intuitive is changes with the target audience, so we must understand who that is, and maybe differentiate between focus groups.
For the administrative software I built, only 1 focus group existed: the user. The user was an employee with a certain level of education and expertise, chosen by a recruiter to be in that function. If there were several users, they would all have a similar level of education and expertise, so no differentiation was needed.
When we started building larger, web-based systems, targeting entire corporations rather than single departments or even rooms, the users started to differ, and we needed to make sure our software could be as functional as each user group needed, while maintaining an ease of use that met with their pre-existing software experience, reducing the need for training. At the same time, our systems would have a 2nd interface: for the support technicians.
And then our corporate systems started targeting internet-using customers of our customers, so we were faced with including a 3rd level of UI and UX: for existing and new customers.
I was there when the WWW went public. I was there when CSS and Javascript were invented. I was there when web 2.0 happened, and visitors became users and contributors. I was there when conversion happened, and visitors became potential customers. I was there when social media happened, and when companies recognised the need for web care. I was there when front-end development became its own job, and UI/UX design matured. I am still here today.
And I could work for you.
Later on (say, turn of the century) the company's focus changed to create web-based applications connected to either existing or entirely new back-office systems. Having sound experience with both, I was chosen to head my teams. Around that time the differentiation between front-end, middleware, and back-end became solidified, and a new kind of professional stood up, who focused on UI and UX only, 2 kinds of work that for me and my colleagues always had been part of our daily jobs.
As such, I am now known as a full-stack developer. I can do all of the work (if I am familiar with the technology stack), starting with gathering customer requirements, ending with training them and their customers to use what was built, and everything in-between. With that experience I realised that I prefer not to do everything by myself, and instead like to have specialised technicians execute dedicated parts of the project.
I never lost my touch with UI development and UX design. I believe that the best interface is no interface at all: let's just get to the desired result. I understand there are choices to be made before the end result is available, and the interface must make it as easy as possible to get there. It should not pose problems. It should not restrict access based on arbitrary choices like a technology stack, screen size, or bandwidth, nor restrict functionality to people with disabilities. It should be intuitive, and of course what intuitive is changes with the target audience, so we must understand who that is, and maybe differentiate between focus groups.
For the administrative software I built, only 1 focus group existed: the user. The user was an employee with a certain level of education and expertise, chosen by a recruiter to be in that function. If there were several users, they would all have a similar level of education and expertise, so no differentiation was needed.
When we started building larger, web-based systems, targeting entire corporations rather than single departments or even rooms, the users started to differ, and we needed to make sure our software could be as functional as each user group needed, while maintaining an ease of use that met with their pre-existing software experience, reducing the need for training. At the same time, our systems would have a 2nd interface: for the support technicians.
And then our corporate systems started targeting internet-using customers of our customers, so we were faced with including a 3rd level of UI and UX: for existing and new customers.
I was there when the WWW went public. I was there when CSS and Javascript were invented. I was there when web 2.0 happened, and visitors became users and contributors. I was there when conversion happened, and visitors became potential customers. I was there when social media happened, and when companies recognised the need for web care. I was there when front-end development became its own job, and UI/UX design matured. I am still here today.
And I could work for you.
Need problem solving?
Talk to me. Let's meet for coffee or over lunch. Mail me at “omegajunior at protonmail dot com”.