In my last post, I explained that I’ve been tweeting about a Big Up-Front Design project and folks have been replying to me that I’m Doing Agile Wrong.
To which I replied, via that post, that Agile is a development methodology, not a design methodology, so of course my design process isn’t “agile”.
There’s more to the assertion that my choice to use Big Up-Front Design is wrong than the semantics of the word “Agile”. There’s an implied belief that anything involving up-front work is inflexible and bad.
Today we’re going to talk about what the word “Design” means in Software Design vs UX Design.
TRUTH #1 Big Up-Front Design has multiple meanings
What does it mean to do Big Up-Front Design?
In a general sense, it’s any time we do the bulk of the planning for a big thing we need to implement before we implement it.
When I say I’m doing Big Up-Front Design, as a UX Designer, I’m referring to the gathering of user research, scenarios, personas, etc. to form wireframes (and even prototypes or detailed specs) before developers start coding. I want to know (and want my client to know) what the happy paths are, where the business value is, and even sometimes which bits are going to be the expensive ones.
When developers talk about Big Up-Front Design, they could be talking about my job, but there’s a better chance they’re talking about the software development methodology which requires the software to have its systems design, database design, etc. all drawn up before coding begins. Big Up-Front Design refers to Software Design, and looks a lot like Waterfall.
TRUTH #2: Software Design doesn’t look anything like UX Design.
Software Design is a very different thing from product design.
Software Design is a discipline in which the Designer documents how the software itself is designed to use quality coding structures and data structures. We’re not talking about how the interface works, but how the application’s code is created.
The difficulty of using the term “design” in relation to software is that in some senses, the source code of a program is the design for the program that it produces. To the extent that this is true, “software design” refers to the design of the design.
~ Wikipedia
Software Design is where the development team figures out things like:
- What is the best abstraction of the logic for this code chunk?
- How do we refine the requirements from high-level statements to lines of code?
- How do we make the code modular enough for reuse?
- How do we architect the software?
- How do we define the hierarchy of control within the software?
- How do we partition the software structure?
- What do the different data structures look like?
- How do software procedures run?
- What information-hiding techniques are appropriate in the software?
TRUTH #3: Big Up-Front Software Design can be more troublesome than Big Up-Front Product Design
As we covered in my last post, the goal of UX Design is to help clients define their products based on user goals and business needs.
The goal of Software Design is to help the developers define how they’re building the product.
There’s an interdependency there. A software design is only as strong as the requirements that help to define it. The requirements depend on the client knowing what they want. UX Design helps the client figure out what to build, so that the development team can then tackle how to build it.
Let’s say we have a client that’s contracted for a specific piece of software to be built, and let’s say that the Development team has opted for an up-front design.
If the client has a product design in hand, gathering up-front requirements is going to be easier, and writing a strong software design will be more successful (at least until the client changes their mind on the feature set).
If the client is still at the stage where they don’t understand what the user needs or how they’re going to deliver it, then the requirements gathering is going to be bumpy. If the dev team still chooses to do an up-front software design, it’s either going to be based on educated guesses on one end of the scale or it’s going to be incomplete on the other end.
This is not to say that a Big Up-Front Product Design is required for every project. It’s not. In-sprint UX design is certainly feasible on a lot of projects.
It is to say that a good software design depends on a good product design, so the product design must be produced earlier than the software design.
Since a good UX design can identify flaws in the product idea before developers are engaged, a product design that is created before the software design can not only save money by getting the right requirements, it can save a lot of money by identifying a product that should never be built in the first place.
CONCLUSION:
If someone says Big Up-Front Design is risky because it’s inflexible, well, there’s a grain of truth to that.
But there are different kinds of Big Up-Front Design and the UX Design type is less risky than the Software Design type, so the size of that grain of truth needs to be scaled accordingly.
Go to the next post on this topic, Doing Agile Wrong: When is Big Up-Front Design Right?
