[Webinar Recording] Building Better Architecture with UX-Driven Design

Watch the webinar and learn:

• An introduction to Wireframing tools
• Proven ways to save on post-first deployment costs
• Insights into better customer relationships
• Better focus on development without 'analysis paralysis'

Building Better Architecture with UX-Driven Design on Vimeo.

You can find the slide deck here: https://www.slideshare.net/sharpcrafters/building-better-architecture-with-uxdriven-design

Video Content

1. Need for Two Architect Roles (10:12)
2. UX-Driven Design in Three Steps (19:02)
3. UXDD Summary (24:35)
4. Related Terminology (32:33)
5. Three Levels of Prototyping (37:05)
6. Bottom-Up vs. Top-Down Approach (44:27)
7. Q&A (53:46)

Webinar Transcript

Dino:

Hi, everybody. I'm here today to share essentially, a few ideas about how to take advantage of techniques that I collectively call UX-Driven Design, to help us building better architectures and software architectures. The first issue that everyone, every developer, every architect runs into in any software project is making sense of estimates and making sense of requirements. We all know ... We are familiar, very, very familiar with a statement like the one you can see taken from an interesting book called 'The No Estimates Book', that attempts to promote a slightly different and alternative approach to making estimations around software projects. Anyway, the quote says, "A good software project must, like a house, start on the strong foundation of good architecture and good requirements" and I guess, everyone would agree with that. But, the problem is that in software, nobody asks you to simply build a house. You know how it works.

The customer or maybe, even worse. The marketing people will approach you and try to convince you that all that the customer needs is a small and it's a very simple thing, very basic. Nothing really serious to be worried about, but soon it grows slightly bigger and more ... Requires, more importantly, a more solid foundation and this is what we call a hut. But, the hut then is not enough, because it has to be these days mobile. It has to move around, across platforms. Across devices, across whatever, so from the hut we move up to the caravan. You know how it works, in the end they ask us to build a castle. But, the problem is, we never know since the beginning where we are expected to go. All that we get from customers is words and as architects, we must make sense of those words. But, words are of different types, they belong.

They express different concepts, as far as requirements are concerned. There are conscious requirements when users express everything that is relevant, because they know all know the details, but then there are unconscious requirements as well. In which, just a few details are often reckoned so obvious that users don't mention that. They just omit it, but they are fundamental for the architect and finally, there are dreams. Everyone that has been a developer at some point or an architect at some point knows about users' dreams. Those things that they wish to have, but they could even have, but they never mentioned them. In the end, if we want to try to make more financial sense around software projects, we must in my humble opinion find out a way to improve the software development process. In other words, we need a better way to learn. Now, which way?

Here is a couple of funny laws, funny because they express a concept that as architects and developers, we are pretty much familiar with. But, the Mr Humphrey mentioned here is a scientist, so he is not a funny person. Funny, because of the effect it may have on us, but why it's serious. The Humphrey's Law mentions that the user of the software won't know what she wants, until she sees the software. I'm sure that everyone here is smiling, oh I know that. The other lemma to this Humphrey's Law is the Wegner's Lemma. An interactive system can never be fully specified, nor can it ever be fully tested. We may smile and laugh at these things, but at the end of the day they are absolutely pieces of truth, so we must cope with these two pillars and build our new way of learning about software development. Taking into account, these two facts.

There is another fact we have to think about, that drives us straight towards the foundation of this webinar. If you wait until the last minute to complete the user interface, at that point it only takes a minute and this is the foundation of the message. The foundation of the sense, of this UX-Driven Design approach. We never, ever spend enough time on the building and more importantly, on the thinking of the user interface. The main problem here is not much, the user interface intended to be a collection of graphical things. Artifacts, colors, styles, CSS. This or that, but it's just the definition of the interactions expected between the user, any user in the system and the system itself. In a way, the concept that I like to associate with the popular idea of the user interface here is close to the idea of the use case diagrams you may know from your exposure. Your past exposure to the UML modeling language.

It's fundamental to have clear, which interactions should take place between users and the system. You know that every software in this world, many great ideas have been first sketched out on paper napkins. Paper napkins or just paper and a pen. Even, in the days in which everything is done through a computer, still play a role. Because, they are extremely intuitive ways to save, jot down ideas. But, in software, jotting down ideas is great. It's good, it's still effective, but to paraphrase a popular sentence of Linus Torvalds. "Talk is cheap, just show me the product" and this is what customers want. How can we show customers the product, because talk is cheap? How can we do that, in a way that is cheap to us as well? If we could find a way to show customers in a cheap or any financially sustainable way, the kind of software we are going to write.

The kind of interface we are going to produce, we gain significantly in terms of the immediacy of the message. If there are missed points in our understanding of the system, there is a significantly higher chance that those missing points will be caught at a good time. Not to compromise significantly and to make more expensive the development. In doing so, if we focus on providing screens and wireframes, and sketches of the user interface. Whether, on paper or not, we learn about the system in a way that is strictly focused on tasks and actions, that the user has to take with our system. We learn a lot more about the processes that we are then called to implement, but we learn about those processes. Not much, in terms of the physical workflow we have to implement in the backend, but essentially and primarily from the perspective of the impact that those processes have on the way that users work with the application.

We write software, essentially to replace. To help users doing things with computers, we are not necessarily expected to change the processes the way in which users do their own things. We have to lean those processes and then, simply map those things to software artifacts we can work with. In other words, the front end of a software system and the backend must match. If I have to find an abstract reason for many software projects, to be financially not much sustainable these days. It's just because of the front end and backend that don't match the way they should.

Need for Two Architect Roles

Let me confess that I really love actually, quotes. Here is another one, this time it's taken from the Matrix, the popular movie. Who is speaking is Morpheus and this character at some point says, "Remember, all I'm offering is the truth. Nothing more." That's what I'm trying to do now. The piece of truth I want to share with you today is that, we need to have ideally two architect roles around our team. I mentioned roles and I mentioned the word 'Architect.' The first type of architect role is essentially, the software architect. The classical, canonical software architect which is facing the painful truth of user requirements. The other one is the UX architect, the new one. The new entry, who is expected to face the blissful simplicity of the user interface. The software architect collects business requirements with a purpose of building the best possible domain layer, whereas the UX architect collects usability requirements to build the best possible user experience for the presentation layer. We are talking about two different architect roles, focusing on different layers of a software system. The domain layer, the backend where we have business logic, where we have business rules implemented and the presentation layer where we have instead the face of the system shown to the face of users. We want to be as smooth, as pleasant, as comfortable as possible and these two architects will work together.

Tony: Excuse me, I have a question here.

Dino: Yeah, sure.

Tony: You are talking about two roles here, is it possible that these two roles are actually represented by one person?

Dino:

It is possible, definitely. Not coincidentally, I titled the slide two architect roles. The role is a type of work that must be done around a software project. Definitely, it can be the same person with enough skills or it could be two different people. I'm not saying that every team should hire a new person, but every team should have a person that is perfectly sensitive to the needs of the usability, as well as the needs of the business roles. Yes, to answer your question.

Tony: Okay, thank you.

Dino:

You’re welcome. The UX architect, a new role. Let's find out more about the responsibilities, so what is the job that is associated with the additional architect role in a software project? Primarily, the UX architect is responsible for something we can call the architecture of the information. The way in which information is distributed across the screens and dispatched to the values, and personas. Persona in the jargon of UX is essentially, a type of a user and user machine interaction. How we distribute information, how we organize information and how we dispatch information to users. Using, which kind of interaction that users love, so it's about how telling to users how you want to do this task. What is your natural way of performing this task and what kind of information you need, at every step of the procedure that represents the process.

This is apparently, something totally completely obvious, but in practice this is not ... This has very little to do with how we do things together, today. Today, we essentially focus too much at the beginning of our tasks in the understanding of what could be the ideal way or the cooler technology we want to use. We would like to use in a project, so we focus on how to parse this data. How to lay out our data, the data that represents and configures the state of the system. We typically, as software architects, ignore until the last minute what is the really required ideal architecture of the information for users and that information that will make the interaction between users, and machines pleasant as it should be. How can we verify the goodness of any idea, any type of user interface we may work with, we may offer?

There are usability reviews and usability reviews is a new entry. There are unit testing, which is good for validating the performance, but usability reviews are essentially the unit testing of usability and presentation layer. I'm not talking about or not necessarily and not only about automated UI tasks. That could help, but this is something that happens at the higher level of abstraction. It's about figuring out learning from users at work, with our prototypes. If they love it, if they like it. If they feel comfortable, if they find it simple. When you send an email and ask users for feedback and the answer you receive is, it's so simple. Then, you have done a great job, regardless of the fact that it was really easy or not to make it that simple. But, making it simple for users is the goal, is the absolute measurement of performance.

It's the measure of performance for good software architects these days, so what does it mean? What it could mean, evaluating the usability of a software system. Essentially, you do that looking at users while they work with the system. Even, recording them. Even, filming them and learning from the body language. There is a little bit of a cognitive sciences here, some of those principles. It may be, you or a team of experts to extract the real feedback and the way in which you interpret the body language. Could be just reading through the emails or looking into their faces. If you see them or just hiring a separate team of people, who can do the analysis for you. Another important point, another practical approach you can take is monitoring the timing of operations or at least, the operations you reckon important in the software.

This is something you can even do via software, by placing tools around your sensitive calls, that log the start and the end of operations. Then, report those times to some remote database, for further analysis. In some cases, it's just a visual kind of analyzing, in some other cases it could be delegating the task to a separate team of experts. With, psychologists and experts in the cognitive sciences. In some other cases, it can just be extra software. Logging and providing software, not measuring the performance of the software itself, but measuring the time it takes to perform certain visual operations. 

UX-Driven Design in Three Steps

These concepts altogether form something I like to call UX DD or for short, UX-Driven Design. In three steps, UX DD can be summarized as follows. Step number one, create screens, as users love them. Iterate on this process, until you reach the stage in which users really tell you they love the screens you have.

Second step, once you have finalized those screens. It means that you know at that point, with an acceptable degree of certainty what goes in and out of each screen you are expected to have. For every piece of user interface you present to users, you know exactly because you have a sketch of that screen. Exactly, the data flow, in and out what has the user has to type. Has to enter in that screen and what the user is expected to see after the operation starts from there has completed. You know exactly the input and the output of the workflow, you have to trigger on the backend to serve the input from the UI. At that point, you have the screen. You trigger a workflow that takes just the input data as users have entered that into the screen and the workflow at the end has to generate the next screen that presents exactly the information that you can learn from the screen you have. Once you have this point of contact UI and the topmost part of the backend, whatever leads underneath that level is the pure backend.

 

It just consists of essentially, attaching some code and some business logic to those workflows. It's just about filling out with logic and code, and action the workflows. These three steps ideally don't take place sequentially and not necessarily in a single cycle. Ideally, I envision UX DD to be split in two parts, so there is a sequence of strings done initially where you iterate using the classic agile feedback loop to work, and rework. Learn and rework the screens, at that stage in the first step of UX DD, you hardly write any code. You typically work with sketches and with tools that can help you, dealing with digital sketches. There is a good number and still, growing number of new tools emerging in this area. Tools for wireframing, I will be mentioning a few of them later on. The breakpoint that I put on screen here, after the create screens as users love them, that is the point in which you can sign off whatever that means with your users. We are now start coding and we code exactly to that set of screens.

Sign off means all and nothing, the term sign off in this context can be intended as the signature put on some binding contracts. If, you are for example, a software consulting company. But, it could even be just an agreement, verbal agreement with customers if customers are for example internal customers. You are essentially, a corporate developer, so I see a logical breakpoint in between the first step and the other two, versus the actual concrete implementation of this breakpoint. May be different from project to project and from team to team. After that, the second half of the UX DD methodology is about writing code. Essentially, coding the backend and also, coding the mechanics you need to have on the user interface. The second part is just coding in the regular agile feedback loop. The sign off is the guarantee that you have more than ever chances to deliver at the end of the day the software, that is really close to the real expectations.

UXDD Summary

Summary, UXDD can be described as a two phase waterfall methodology. Two phase, because there is a logical breakpoint in between the first wire frame analysis and the actual coding phase. The benefit is that, the extra steps or the step wire framing that is receiving a lot more attention today. Apparently, we spend more but the more we spend is essentially, a low cost activity. Because, we use wire frames and no code, the sign of the front end. The analysis on the front end is essentially, a low cost thing. In return for this small extra step, we have all set for a straight implementation on the backend. We have great chances to make it right, the first time. In summary, slightly longer than classic, bottom-up architecture approach. But, on the upside, nearly no post-deployment costs. Yes, no post-deployment costs and this is the real point that could make the difference.

Tony: I have one more question here about this.

Dino: Absolutely, sure. Yeah, sure.

Tony: You say there are no post-deployment costs, do you mean just costs by fixing issues which were not caused before during the development or is it also about support, which usually doesn't have to do anything with bad design or something like that?

Dino: I think, it's both things. Primarily, the cost that in my opinion and for what is my experience, because by the way I'm practicing this every day. It's just the cost of fixing things, because they don't provide exactly ... They don't let users work exactly in the way they need. It's about work taken out of support and also, work done fixing small, little things in the UI. Just add this piece of information here, can I have the list prefilled or this information sliding in at a certain point? It's both about the support and also quick maintenance. The type of quick maintenance you typically do, right after deploying it.

Tony: Okay, right.

Dino:

You're welcome. I think, it was a couple of years ago. I've seen the picture that is going to appear on screen just in a few seconds, which was Tweeted by a European MSDN account. I don't know if it was MSDN, Italy, France, Germany. I don't even remember, but it was one MSDN account who presented this picture, to say this is how you see your system has a tidy, ordered sequence of layers. The data, then on top of the data, the business logic. Finally, on top of the business logic, the presentation. You see, there is a classic bottom-up way of development, data business presentation. This is how we, as smart software architects, think that software should be done and this is instead how users see our system. A layer of interface and underneath that, under the covers. Under the surface, just like magic. The funny thing is that when this tweet was made, the sense of the tweet itself was just that of a joke.

We are so smart, that we know how to create, design systems and let's look at how dumb users can be. Because, all they are interested in is, user interface and whatever else. All the effort we put into the system to their eyes is just black magic. That's the key point, that's exactly how users see our system, but that's not how we build actually the system. Let's take another perspective on the same point. Imagine, we talk about carrots. If you are a developer, a carrot is for the most part, under the soil. Every carrot has a huge taproot and just small leaves over the soil. But, if you are a user or if you are a designer, it's quite the other way. The leaves is not simply leaves, but they are an actual tree and the taproot is whatever else that you don't see, because it's under the soil. But, the real world is neither, the world has developers see it and nor, the world has users, and designers see it. The real world shows that a carrot has a significantly long taproot and significant leaves. More importantly, the two things grow together.

At the end of the day, UX Driven Design is about mimicking, mirroring how carrot's leaves and taproot grow in the real world. This leads us straight to formulating the definition of user experience. User experience is nothing fancy, user experience is simply the experience that users go through when they interact with the application and we do want that the experience they go through is as pleasant as possible. Otherwise, we failed and look, we failed here means essentially we have spent. Our company has to spend more time, more money, money effort. More resources on fixing those things and experience shows that companies lose good money on that extra effort. There is frustration in the developers involved with that, there is frustration on the users end also because they paid for something they can hardly use. They have to adapt themselves to the thing we have delivered and nobody is happy, so it's a lose-lose kind of thing. Paying more attention, a lot more attention on user experience becomes or has more chances to become, or to really be a win-win kind of thing. We learn more, we do best and everyone is happy. 

Related Terminology

When it comes to user experience and the way we can learn our way through that, there are a few terms. A few words, a few expressions, terminology that look related and is often used interchangeably, but those terms however have some significant and specific meaning. The first term I want to call your attention on is sketch. Sketch is defined as a freehanded drawing which is primarily done with a purpose of jotting down ideas. It's the classic thing we do on the paper napkin of some cafeteria. The wireframe is another term, which essentially identifies a more precise sketch that contains more information. Precisely, it extends the concept of wireframe with information about the layout, about the navigation about the content we are going to present in each, and every screen. Third term is mockup, which is nothing than a wireframe where a lot of UI graphical details have been specified.

A mockup is a wireframe with a sample UI attached. This set, this is the real meaning and these are the three levels of wireframing activities you can find. But, be aware that depending on the context, these three terms may be used interchangeably to mean something that in the end is very close to the idea of a wireframe. Of these three terms, the central idea that is strictly related to UX DD and in general, learning about processes through the UI. The key term is wireframe. Other three terms related are proof of concept, which typically identifies a small exercise with code done to verify the truthfulness or just the viability of an assumption. Or, another scenario pretty common for proof of concept is, getting yourself started. Familiar, with a new technology, just to see if it could work and if it could be used to implement certain features of your system. Prototype is yet another term, but the prototype is not a small exercise actually.

It's a fake system that simulates the behavior of a real system, the real system to be built. When you build a prototype, you are miles away from the real system, even though the goodness of a prototype is making the fake thing look like the real one. If you have one a good prototype, the sign that proves this is when users say it's half done or it's already done. No, the hardest part when you have a good prototype in your hands is telling users it's just a fake thing. The real one is miles away. The pilot is instead a production ready system, the difference between the pilot and the real system is essentially not in the functionality, but the fact that it's tasked and put in action against a subset of the intended audience or the intended data. Anyway, proof of concept, prototypes, pilots are again, terms that depending on the jargon spoken in each company can be used interchangeably. But, again, the central term, the most important thing is prototype and prototype ties up nicely with the concept of wireframing. 

Three Levels of Prototyping

At the end, UX DD identifies three levels of prototyping. Basic understanding of functions, which is typically done via sketches. Very simple, very basic wireframes. Basic prototyping, which is when you essentially go deeper and rewrite sketches into something that is much closer to the real sequences of steps in the process. You get a lot more granular when you move from sketches to wireframes and then, sometimes this is not enough. Not always, not necessarily, you can go and talk to users, just about wirefreames. Wireframes are nice, are PDF files, are PowerPoint kind of things. But, there is no action, even the most detailed wireframe is essentially a storyboard that the users can view as a sequence of hyperlinked screens. But, there is no action, no fake data. There is nothing there that gives the sense of the real application. The term that is advanced prototyping and advanced prototyping is done with code. We are back to square one, so back to the issue that it is expensive to do that.

Tony: I actually have a question here.

Dino: Yeah?

Tony:

You say that we need to create prototypes during the UX DD process. Where are actually the savings here?

Dino:

The saving, if you ... Essentially, if you write the prototype because it's required, because users ask you to show something that looks like the real thing and this happens very often. Not always, but very often. Then, the challenge is not using deep code to build the prototype. Ideally, building the prototype without even creating a visual studio project. This opens up an entire new world of tools, that allow you to achieve the level of prototypes from wireframes. The trick, the lever that makes UX DD really affordable is using a different type of tool side-by-side, with a classic Visual Studio or IntelliJ. Whatever kind of framework you use to write your software, it's having a dual set of tools that could work together and the wireframe is created at some point with one tool. If that tool is particularly smart, you can just derive from there the prototype or if you're unlucky, or if the project is particularly large and big. Okay, prototypes is writing code, but anyway the idea. The experience proves that any effort you put up front tends to be essentially paid back, paid off by the saving at the end of the project. The work you do in advance is much easier to code to customers, that's not a secondary point.

Tony: Okay, thank you.

Dino: You’re welcome. A few products that can help you out with having some preliminary work done around wireframing and around quick prototypes. The entry level tool in this area is BALSAMIQ and BALSAMIQ is a relatively cheap piece of code, that allows you to work in a PowerPoint style. You drag and drop artifacts, graphical shapes to a drawing surface. You compose those things together, you group those things together and the most you can do is linking some of those elements to another view so that you can simulate a storyboard. The effectiveness of BALSAMIQ is that you can save those things as a PDF file, taking advantage of the hyperlinking internal feature of PDF files. All you send to users is a PDF file and you can have users to navigate through the screens, just having an idea of the way in which they will be doing the real thing. Nothing is real here, there is no data. Nothing is live, it's entirely static but it gives an idea and if you need more, there are three other tools that I'm aware of. There might be probably other tools as well in the industry out there.

AXURE, UXPIN, JUSTINMIND. These three tools are nearly doing the same and they do more than BALSAMIQ. They are also more expensive than BALSAMIQ, in terms of licenses and prices. I'm familiar particularly with AXURE and with AXURE, you can create wireframes in much the same way you do in BALSAMIQ but you can easily turn those things into code, into working prototypes that are delivered as HTML, JavaScript and CSS websites. From the tool itself, you can upload and share via a dedicated cloud the prototype for users to play with. The functions that the tool makes available allows you to have a can of data. Pre-field screens random data automatically and you can even add some quick action, essentially using JavaScript code. You don't have to be a developer to use AXURE and usually, AXURE is not used by developers. Yet, with AXURE, you can produce something that really looks like in terms of colors, in terms of layout, in terms of navigation.

In terms of real user interface, look like the real application and can even be the starting point once approved for building the real facade. The real presentation, the real front end for the real system. 

Bottom-Up vs. Top-Down Approach

To finish off, I just want to show you now the difference between the bottom-up and the top-down approach, so that you see once more from a different perspective what is going to be ideally and hopefully beneficial out of UX driven design. The bottom-up approach that we are, everyone is familiar with I guess, starts from requirements and then based on the requirements, we create a data model. On top of the data model, we build up the business logic and then, we just stick some user interface on top of the business logic. It works, where is the problem? The problem, for many years, didn't exist. The problem started existing in recent years, when probably following the introduction of the iPhone, the entire mass of users out there started changing their mindset about the way in which they interact with software. Users started hitting, rightly, the need to have data at hand.

Information at your fingertips Bill Gates used to say many years ago, but never in my opinion that concept turned into reality. What is the problem when the user interface is stick on top of that business logic, in a bottom-up manner? Not necessarily the interface of the user interface matches the interface, the bits out of the business logic, so it's a matter of facing a possible likely model mismatch. When this happens, so when the format, the shape of the data you work with in the backend is significantly different from the data expected to be used and consumed in the user interface, you need to have at some point, in some way, adapters. Adapters must be written and adapters must be tested. Adapters must be debugged and it's a cost, and not necessarily those adapters can easily retrieve the data in the aggregation level that is required by the user interface.

When this happens, you know what's the next point? The next point is that you have to spoil the purity, the beauty of your model and leaving holes here and there, for some code to connect through the layers to retrieve the data. The queries, the inner joints, the aggregations that weren't planned right from the bottom, because building from the bottom is never as optimal as doing it the other way around. Top-down, we have requirements and let's say, we start right from the user interface according to the UX DD idea. Then, once we know exactly what comes in and out of each screen we are going to have, we know all possible ways for the backend to interact with the system. We can create a business logic, the topmost part of the backend and give that a model that is cut to fit perfectly with the bits coming out of the user interface. At that point, the data model is just a detail because we create the data model.

We persist the data in the way that suits our needs. We can do that in total freedom, regardless of how we are retrieving data. We can choose, even the framework, the technology, the persistence technology that best suits. The business logic and the data model together are a single element, they are a piece of black magic. We now, in this way, are back to the ideal vision of the software the users have. Just an interface and whatever sits under the surface, under the covers of user interface is black magic. You can have this black magic kind of thing, only if you go top-down and UX driven design offers you a set of practices, techniques, suggestions on how to achieve that. To summarize, there are some other things that nicely fit in this big design, if only you take it a little bit further.

User interface, collection of screens, pins to connect the backend, the application layer and business logic built to fit with user interface. Screens and workflows, and it's clear in the interaction, the input model that flows out of the user interface and becomes the input for the application layer, and the view model that becomes the output of application, and the input of next screens we present to users. We have here, four different types of data models around. There is the persistence model, how we save data. There is the domain model, how we deal with data in terms of business processes. There is the view model, how we render out and there is the input model, how we receive data from the user interface. Domain layer, infrastructure layer leaves underneath the application layer.

The user experience we deliver is just what users want and we can happily, and comfortably build the backend that is cut to fit, to support just the user experience that users want. There is one more benefit here, CQRS. When you learn about a system, in terms of tasks. Every task tends to be either a command that alters the state of the system or a query that reports the current state of the system. In this context, CQRS makes total sense and it's a nice fit. CQRS recommends that you split your backend into two distinct layers, two distinct stacks. Vertical stacks, the common and the queried stack. The nice thing, because they are separated and because, whatever way you choose to persist and read data doesn't change is transparent to the front-end of the system. There is no reason not to use the technology that fits best. It could be sequel, no sequel, events. Whatever, in memory caches. It can be whatever, for example: It can be an even store for the common stack and a remodel may be sequel, relational real model for the query stack.

In the end, UX-Driven Design just helps us saving cost, especially post-deployment costs in maintenance. But, it helps us to learn, through processes about the domain. Which, also makes us able to suggest new features and grow our business. But, it also connects very well and very clearly with a couple of buzzwords, which are very popular these days. CQRS and event sourcing. All this said, the best way to save money on software projects is learning as much as possible about the domain and about the user expectations. I really don't know if there is someone who said this sentence, probably yes. Probably, no I don't know, I don't even care but this represents however an absolute piece of truth. Okay, so that's all for my end. I will be happy to take a few questions from you, if any questions are.

I just want to thank PostSharp for organizing this webinar and for giving me the chance to talk about UX-Driven Design, so thank you to the people at PostSharp. Which, by the way, is a cool kind of a software that can help in some way to write software in a cost-effective manner. For those of you interested in sort of a followup or in some other resource that goes beyond the boundaries of the webinar. I have a couple of Pluralsight course. Actually one available today, which is in top hundred of Pluralsight courses. Modern Software Architecture, where I talk about domain model, CQRS and event sourcing. There is another one, more specific on UX-Driven Design, which is expected to ship pretty soon. I was hoping to have it available within the end of the year, but it will probably slip to January. It's a matter of weeks anyway, to have UX-Driven software design available in the library of Pluralsight. What else? If you don't mind, follow me on Twitter and thank you very much for your time.

Q&A

Q: Maybe the issue is to stop trying to give the customer what she wants and together, as architects, we should give the customer what she needs. Then, work to persuade her why that's better.

A: Sometimes, this works and sometimes, not. Yeah, understanding what the customer needs is the ultimate purpose of the architect but however, not necessarily our understanding. What we believe is what the customer needs is exactly what the customer needs. It's true, it's correct. However, it relates on how deep is our knowledge that's it. How we manage to understand what the customer really needs. Persuade the customer that something is best, is better? You can do that, but I have a recent experience this week which I'm trying to convince the customer, that the different architecture of information will help her to work more effectively. But, she's coming from a mindset that has taken her and all of the team in expecting data to be laid out in a certain way. No matter, the confusion that can result on screen, that's the way they love it. There's no way to persuade these people, so if you, definitely. Otherwise, I don't know. It depends, it usually depends.

Q: I'm not sure the front-end and backend should match, surely the reason why for each is very different. The UX is contextual and should be tuned to the needs of the now, whereas the backend should be focused on stability. Extensibility and future proofing the data. The front-end should be specific and the backend, generic.

A: In a way, yes. This fits nicely with some of the concepts borrowed from domain-driven design and in particular, the layer. The architecture and the fact that the business logic, the domain logic, so the part of the business logic that never changes that is not dependent on processes. That should be isolated from persistence and from processes. Yeah, exactly. In this context, the business rules go into a layer isolated, which in domain-driven design is called the domain logic. That is that persisted to typical databases, but it's also injected into something that is called application layer which is the point of contact. The facade, the proxy in between the front-end, the presentation and the domain logic. Out of the domain logic which is static, in the sense that it's shared and common. Then, can be optimized for whatever, for business. For performance, for relatability and whatever else. It's about the processes and the processes should be taken out of the logic and made to measure, to coordinate with the needs of processes on the backend of the expectations of users. The application layer plays a key role here, because it's the facade between the front-end and the backend.

Q: What happens in the middle of the backend sprint. If you realize you are missing a screen, should you have it designed within the sprint or wait for the next one?

A: It depends on how relevant is the screen that you realize you're missing. Probably, yeah. I would try to get that fixed in the sprint you're in, so in the second sprint you're in without waiting for completion. I would be ... The purpose is delivering what they need as soon as possible, so if a screen is missed I would try to violate, in a way, the sequentiality of the two waterfall steps. Have the screen added, with all the details, in the context of the development sprint. Unless, there is some contractual issues, so if you signed off and there's a contract that financially binds you to deliver something. At that point, if you miss a screen, it's a matter of legals to lawyers or to experts, to kick in and see how the contract has to be rewritten to let you do that kind of work extra.

Q: If it's agile then how common this that we can see there is no post-deployment cost or there is no post-deployment at all in this process?

A: It was more or less the promise of agile to ... If you talk to customers during the entire cycle, then you deliver what they need at the end of the final sprint. But, actually this is not what most people are experiencing, so there are post-deployment costs. If someone doesn't experience that, okay. Good, it's great. Fantastic, but that's not ... In my experience, it's not exactly the point and that is that primary ... The major source of extra costs in the midst of the project is my experience.

Q: Is UXDD applicable for data driven apps such as most enterprise apps, like in banks?

A: It’s mostly about your interaction with users, whether consumers or corporate or whatever. I’ve seen UXDD similar things applied in a large (very large) pharma company. Missing link was that they simply split design of UX and design of code in two steps but design of code was done bottom-up. In general, I see benefits everywhere mostly because that helps taking a task-focused approach to the way you learn about the domain and processes. Particularly relevant I guess in enterprise business.

Q: What is the best system development process to use with UXDD - e.g. DSDM?

A: I see UXDD as two agile steps. And agile means what it usually means to you. But in some organizations distinct steps are problematic. In this case, I tend to see the first UXDD step (wireframes) as a sort of sprint zero. Possibly a repeated sprint zero not repeated for each sprint but more than once.

Q: How best to handle a situation where the cost to implement a screen is a very high? What if there is a better way to implement at a cheaper cost but at a sacrifice of usability.

A: As long as it keeps customers happy, any UX is fine. But users can appreciate MORE and MORE a UX that is super-simple, easy to understand, tailor-made to processes and friendly.

Q: I've heard a lot of from managers, that UI can be generated by data. So the data is essential and for hardcore enterprise it is tabular data. There are numbers of solutions for that approach. Devs modeling data, domain and then get UI for free - from the managers perspective. Any advice on how to convince those managers?

A: Unfortunately data is less and less simply tabular. And users are less and less willing to accept whatever UI a system can autogenerate. That’s precisely the mindset UXDD attempts to address. The simple answer (and most concrete) is that you save money after deployment. Money in terms of support work, fixing bugs, fixing logical bugs. If you don’t run into these problems, you’re probably OK as is.

Q: How is multiple UX Designs handled for a single data model? I mean if i have different UX for different devices rendering the same data how is that handled in UXDD?

A: Multiple frontends (like Web and mobile) talk to possibly different application layers and application layer is the topmost part of the backend. Under the application layer you find the reusable domain logic. Different UX may refer to different processes that orchestrate common pieces of business in different ways. Different frontend match possibly different application layers. (Application layer is one of the layers of DDD layered architecture. The place that orchestrate use-cases.)

Q: Can you please give an example of working with the top down UXDD approach and adjusting the business logic requirements. What is an example of adjusting the Business Logic to fit the User Interface? For example, if we learn that what users need is out of scope with project scope/timeline/resources, how can we affect the Business Logic?

A: The key fact I see behind UXDD is simply that everything starts from the top and only once you’re satisfied with the UX you start arranging the backend. How can you effectively design the BLL if you’re not sure about what users want? BLL is just the next step after UX or the part of UX that fits your scope/timeline/resources.

Q: When performance tuning comes into the place? During development or at late stages of development when you have UI defined completely?

A: UI and the backend share input and output and defining those things is the primary purpose of UXDD. At that point UI and backend can be optimized separately.

Q: Was UML to purpose this idea? And now MS removing it?

A: UXDD screens are essentially implementation of use-cases. And use-case diagrams are a foundation of UML. But in my opinion UML is too much and too cumbersome. Too many diagrams and formalism. But yes there’s some reasonable conceptual overlap.

Q: What's an example of an Event Store?

A: An event store is a database where you store the state of the system in the form of events (this is event sourcing, or having events as the data source of the application). Technically, an event store can be a NoSQL store (Mongo, DocumentDb, RavenDB) but it can be a JSON-friendly store (SQL Server 2016) or specific products like EventStore. Learning about Event Sourcing is helpful.

Q: What you think about "Advanced Prototyping" level with following workflow (e.g. we are working with ASP MVC):

• 1) First we implement prototype in ASP MVC Views with faked ViewModels.
• Use fake ViewModel Repositories, which in future we will replace to real.
• Not repositories of domain objects, but repositories of view models.
• At that time there is no domain objects and logic.
• 2) After some iterations we have working prototype and then we implement domain objects and logic. And connect domain model with view model.

A: What you describe is what I did no more than a couple of times. Today ad hoc tools exist (ie, Axure) that can do most of the work for you and generate HTML frontends with fake data in a PowerPoint style way and a bit of JavaScript knowledge. A work non-developers can do. At the same time, these tools can create only storyboards—sequences of hyperlinked pages. If you need a bit of logic and realistic data in the prototype, then it’s a prototype and what you suggest is probably the least expensive way.